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ABSTRACT 
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processor. The remaining tasks are allocated according to a heuristic function that 
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messages. 
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pairwise interchange of tasks that considers interprocessor communication distances. 

The overall scheme of task allocation was successfully tested and analyzed 
through simulation of several applications on a transputer network providing a near 
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I. INTRODUCTION 


A. ELEMENTS OF PROGRAM EXECUTION ON MULTICOMPUTERS 

PEneo ele aCVeiE OL Very large-scale integrated (VLSI) 
circuits, computer hardware has decreased in size and cost. In 
addition, the employment of higher-performance parallel 
computers has become essential for several modern applications 
such as weather prediction, computational aerodynamics, 
mere retal sintelligence, and military command and control 
systems. Therefore, new software tools are required to exploit 
the parallelism on these machines as well as to provide 
transparent program development systems to the users. 

Concurrent computing using multicomputers requires a 
Mapping between the user application and the processing nodes. 
This mapping procedure is usually decomposed in distinct 
elements to make this complex problem tractable. These 
elements are partitioning, task allocation, node scheduling, 
and message routing, as shown in Figure l. 

PAaGrMeloming 14 Ene part Enat divides the original problem 
into subproblems that are solved by individual processors. The 
solutions of these subproblems are combined to compose an 
@veral] solution to the original problem. Therefore, it must 
determine the computation grain size, which is the number of 


operations performed sal a task between intertask 


communication, and the communication grain size, which 


corresponds to the message sizer 


APPLICATION OODE 


“PARTITIONING 


COMPUTATION & aa COMPUTATION 
COMMUNICATION GRAIN \. GRAIN SIZE 


PERFORMANCE VISIBLE 
TO THE USEA 





Figure 1: Interaction between stages of the mapping procedure 


Task allocation is the component that allocates the pieces 
of program (program modules) obtained from partitioning to the 
processors that compose the parallel computer. Locations of 
the source and destination of messages, which constrain the 
possible shortest paths used in message routing, are 
established by this element. 

Node scheduling considers task features such as 
precedence, execution time and deadline, in order to schedule 


task executions on each node processor. Thus, it affects the 


Pane re = prOLile by determining the instants of message 
transmission from one node processor to another. 

Message routing decides how effectively the communication 
subsystem can be implemented. It considers the minimization of 
network latency, uniform utilization of the network resources, 


and freedom from deadlock/livelock. 


B. REQUIREMENTS IMPOSED BY APPLICATIONS 

Real-time applications impose a diversity of requirements 
that must be considered in the design of the new generation of 
parallel computers. These requirements are not constant in 
time but they can change frequently. For instance, consider 
the problem of scheduling aperiodic tasks with time 
SOvstraints ana rancom interval of arriving, or the problem 
of meeting new system specifications to enhance the original 
System| STANKOVIC 88]. Therefore, the computer power needed for 
such applications as measured in terms of MIPS or MFLOPS is 
not static and should be provided on demand. 

Since the design of new applications implies high 
development costs, it is highly desirable that new systems 
should be dynamic and flexible. Therefore, system designers 
must consider approaches to minimize the number of constraints 
to be imposed on further modifications. For instance, this can 
be accomplished by using scalable parallel computer 
architectures and real-time operating systems with support for 


dynamic allocation of tasks. 


Another fundamental aspect of real-time applications is 
that the correctness of system results is not only dependent 
on the logical correctness of the program but) alsemro nee 
ability to meet the individual deadlines imposed by 
individual tasks. Consequently, critical tasks should be 
scheduled for execution with higher priority than non-critvegm 
tasks. Critical tasks are processes for which the consequence 
of missing a deadline is catastrophic with violation. 
personal or material safety. 

Besides deadlines, task execution times, repetition rates 
of periodic tasks, and precedence between tasks are also very 
important requirements. 

Fault tolerance is another issue that must be considered. 
Multiple instances of the same process must run on different 
processors to achieve the desired reliability. 

Resource constraints are imposed by the system 
architecture. Therefore, tasks are required to share several 
resources other than CPU such as I/O channels, data 
structures, files, and databases. 

Basic to such sharing is intertask communication that may 
result in interprocessor communication. The presence of an 
efficient communication system underlying a multicomputer 
network is a requirement that must be satisfied to minimize 
the effects of delays due communication between tasks residing 
at different nodes. These delays are the cause of the 


saturation effect on the achievable speed-up when using 


multiple processors. In addition, they are not predictable 
causing problems for real-time applications. 

Static systems are systems in which tasks and timing 
constraints such as the arrival times of tasks are known 
beforehand. Dynamic systems are those systems which tasks 
arrive at random times. A static resource allocation scheme is 
required for static systems. This approach can be employed at 
compile-time since all needed information is known then. On 
the other hand, a dynamic resource allocation scheme is 
required for dynamic systems since it has to be used at 
execution time and little is known about the application at 


compile-time. 


C. CURRENT STATE OF THE ART 

tiene shave —~been Many Studies in static scheduling in 
distributed systems. This category of scheduling problems has 
been traditionally formulated as the task allocation problem. 
A useful survey on task allocation problems can be found on 
[STANKOVIC 87]. 

Several approaches to the allocation model have been used. 
They are graph theoretical, integer programming, and heuristic 
methods[TSUCHYA 82]. These approaches pursue solutions that 
minimize the interprocessor communication costs with a 
Ballanced utilization of each processor. 

The scheme presented by [TSUCHYA 82] employs integer 


programming models to find optimal allocation with explicit 


time constraints. A branch and bound search algorithm is used 
to solve the allocation problem. This approach can be used to 
balance processor loads and to minimize communication costs. 
An AND-OR precedence graph with 23 tasks having port-to-port 
timing requirements is used to validate this scheme. This 
model allows the inclusion of several constraints such as 
allocation preference, task exclusion, redundancy, time and 
resource constraints. 

The approach developed by [RAMAMRITHAM 89] uses a 
heuristic-directed search. This algorithm handles periodicity 
constraints, precedence, communication, and fault tolerance. 
Experimental evaluation of the algorithm shows that a task set 
can be feasibly allocated and scheduled, and the algorithm is 
highly likely to find it without any backtracking during the 


search. 


D. OBJECTIVES 

The objective of this thesis is to develop suitable 
algorithms for static allocation of tasks having precedence 
constraints on transputer-based systems. Specialized research 
in Chis field has shown that optimal solutions for this 
problem are NP-hard[QUINN 87], therefore heuristic methods are 
required to find near optimal solutions. 

Several task flows are employed on a transputer-based 
System to evaluate the performance of the allocation 


algorithms with respect to the interprocessor communication 


costs, load balance on each processor and task flow response 
time. 

An existing communication layer software, developed by 
[RICHMOND 91] in ADA, is upgraded to implement task flow 
simulations on a transputer-based system. Modifications to the 
communication layer that were necessary to improve its 
functionality are as follows: 

- Take similar communication routines existing on each 
node main program and put them into a single ADA package to 
make them easy to be reused as well as to improve the total 
compilation time of the distributed program. 

- Use different approaches to route messages among the 
nodes that compose the transputer network. The first 
implementation routes messages in a counter clockwise ring 
fashion only. 

SER cCGuee JeOMmulmlGarilon Overhead an rellataion Lo the total 
execution time of the distributed program. 

- Study how to make the layer more robust with respect to 
deadlocks. 

A network of transputers is used in this thesis for the 
Simulation because it follows MIMD(Multiple Instruction Stream 
VUl~nple Data Stream) parallel architecture providing 
Meexibality for further topological changes as well as 
scalability. Moreover, its use makes the simulations more 
realistic and simpler than purely theoretical models that 


could be built in uniprocessor computers. 


The programming language ADA is used in the current thesis 
due the following reasons: 

- Existence of a communication layer written in ADA 
[RICHMOND 91] that makes the communication between tasks 
location invariant, and 

- Presence of high level ADA constructs that make it 
easier to implement multitasking. ADA has incorporated a 
technique called the Rendezvous[HOARE 78] that combines mutual 
exclusion, task synchronization: and interprocess 
communication. 

- The language is a DOD standard(ANSI/MIL-STD-1815A-1983) 
and has the potential to be the standard programming language 


in the next generation of real-time systems. 


E. THESIS ORGANIZATION 

This thesis contains four chapters. Chapter 1 deseriuped 
the elements of program execution on multicomputers, 
requirements imposed by applications on real-time parallel 
computer systems, a brief overview of the current state of the 
art on the problem of task allocation, and the objectives of 
the present work. 

Chapter II contains the general structure of the 
communication layer including discussions about topics such as 


the AUV flow simulation, deadlock avoidance, characterization 


of the communication performance, and changes to meet new 
project specifications. 

Chapter III describes the task allocation including the 
constructive assignment heuristic, the iterative improvement 
by pair-wise interchange of tasks, and simulations on the 
transputer network. 

Chapter IV states the conclusions and recommendations for 


further research. 


II. COMMUNICATION LAYER 


A. GENERAL STRUCTURE 
1. OCCAM HARNESSES MODIFICATION 

Figure 2 shows the T-800 transputers that compose the 
transputer network used in this thesis. Processor EARTH is 
linked directly to the host PC, and theretore it is tiemoumes 
processor with access to the I/O offered by the PC keyboard 
and display. All other processors(MARS, VENUS, PLUTO and 
SATURN) can only communicate with the host PC by sending 
messages to the processor EARTH. Task SCREEN that runs on 
EARTH can inspect the codes of messages sent by these 


processors and then print suitable messages on the PC screen. 





Figure 2: Communication topology 


10 


Processors MARS, VENUS, PLUTO and SATURN are the 
transputers that run the distributed software for the 
application task flow simulation. The OCCAM harnesses for 
processors MARS, VENUS, PLUTO and SATURN have been modified to 
permit the use of different approaches for routing messages 
Eaeough the transputer network. 

Tables I, II, III, and IV show how the communication 
channels are allocated on the processors MARS, PLUTO, SATURN 
and VENUS respectively. The channel numbers shown in Figure 2 
are the physical link numbers. 


Table I: ALLOCATION OF CHANNELS ON MARS 


BNO VIRTUAL | PHYSICAL 
ANNEL NUMBER NUMBER 

input |garth2mars | 2 =| on 

inpur__|venusamars | 4 | @ 


inpuT_| Pluto2Mars ae 


OUTPUT Mars2Earth 


OUTPUT Mars2Venus 


a 





Table II: ALLOCATION OF CHANNELS ON PLUTO 


IN/OUT VIRTUAL PHYSICAL 
CHANNEL per aed) 


INPUT Mars2Pluto 






INPUT Sat2Pluto 


oe 
oureur | plutozsat | + | 3 


tha. 





Table III: ALLOCATION OF CHANNELS ON SATURN 


IN/OUT VIRTUAL PHYSICAL | 
a NUMBER NUMBER 


input | Pluto2Sat 







PNP UE Ve nits 25aic 3 


—sese 
ourpur_| sat2venus | 3 | 3 






Table IV: ALLOCATION OF CHANNELS ON VENUS 


IN/OUT VIRTUAL | PHYSICAL 
| CHANNEL NUMBER NUMBER 
INPUT race | 


INPUT Sat2Venus 


commer, reucasiass oa Se 
ourpur | sat2venus 





The physical link numbers are associated with the 
hardware communication channels existent on each transputer. 
The T800 transputer has 4 bi-directional communication 
channels that are numbered 0, 1, 2 and 3. The virtual channel 
numbers are logical references to the communication channels 
declared on each main ADA program. 

The Alsys ADA compiler for transputer networks 
requires that each main ADA program to be run in a transputer 
node must have its own OCCAM harness in order to provide a 


clean interface to the program in terms of used channels[ALSYS 


i 


90}. Tables V, VI, VII, VIII, and IX show all OCCAM programs 
that are required for each processor node to run application 
task flows using a distributed ADA program on the transputer 
network shown in Figure 2. 


Table V: OCCAM HARNESSES ON PROCESSOR EARTH 


FUNCTION 


EARTHH.OCC Declares the virtual 
(EARTH HARNESS) channels used by EARTH and 
invokes the EARTH ADA 
program 


EARTHH2 .OCC Declares the entry point 
that is used by EARTH 
harnessy vorcall® the EARTH 
ADA program 


MERGER .OCC LOLlLeCt OULDUEmeELOLG si T Om 
up to 20 Ada programs 


MAINH.OCC Invokes the EARTH harness 
and the MERGER error 
harness 


MAIN. PGM Maps the virtual channels 
of each processor to 
physical links. Invokes the 
following harnesses in 
parallel: MAIN, MARS, 
PLUTO, SATURN and VENUS 





The OCCAM harnesses which declare the virtual channels 
described in Tables I, II, III and IV, and the OCCAM program 
that allocates virtual channels to physical links(MAIN.PGM) 
are enclosed in Appendix A. They have been modified to permit 
bi-directional communications between pairs of adjacent 
transputers. The previous implementation sends messages in one 


fixed direction around the ring. Different schemes of routing 
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Table VI: OCCAM HARNESSES ON PROCESSOR MARS 


r eee EEE 
PROGRAM FUNCTION 


MARSH.OCC Declares the virtual 
(MARS HARNESS) channels used by MARS and 
invokes the MARS ADA 
program 




















MARSH290€¢ Declares” Chervenrey sous 
that is used by MARS 
harness to call the MARS 


ADA program 


Table VII: OCCAM HARNESSES ON PROCESSOR PLUTO 


PROGRAM FUNCTION 


PLUTOH.OCC Declares the virtual 
(PLUTO HARNESS) channels used by PLUTO and 
invokes the PLUTO ADA 
program 


PRUTOCHZTOCEe Declares“ cile entry woe rue 
that is used by PLUTO 
harness to cail the PLUTO 


ADA program 





messages can be used with the new version. 
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Table VIII: OCCAM HARNESSES ON PROCESSOR SATURN 


PUNCT ION 


SATURNH.OCC Declares the virtual 
(SATURN HARNESS) ChannetoeuscempyecA (URNeanad 
invokes the SATURN ADA 


program 


SATURNHZ. OCC DeclanecVelewentry pomnc 
that is used by SATURN 
harness to call the SATURN 
ADA program 





Table IX: OCCAM HARNESSES ON PROCESSOR VENUS 


FUNCTION 


VENUSH.OCC Declares the virtual 
(VENUS HARNESS) channels used by VENUS and 
invokes the VENUS ADA 
program 





VENUSH2.OCC Declares the entry point 
that is used by VENUS 
harness to call the VENUS 
ADA program 





2. THE HOST COMMUNICATION LAYER PACKAGE 

The host communication layer is the software that 
Manages the communication of the host transputer(EARTH) with 
other nodes. This layer is implemented by the generic package 
HOST LAYER enclosed in Appendix B. 

The package HOST_LAYER includes only one task, the 
task EARTH QUE, which implements a circular buffer that is 
used to keep the incoming messages until they can be sent to 


their destination. This task works like a local mailman that 
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is in charge of storing and delivering the messages to the 
local tasks. Further details of this task will be given later 
since its implementation is identical to task QUE of package 
COMLAYER. 

An instance of the package HOST LAYER muscuee 
generated with the procedure SEND_IT, which is the progeamn 
that issues entry calls to the local tasks passing the 
messages to their destinations. The procedure SENDSii me 
called by task EARTH _QUE. 

An instance of the package HOST _LAYER is created in 
the main program EARTH.ADA, which is also enclosed in Appendix 
B, with the procedure SEND_IT _FROM_EARTH. This procedure sends 
messages to the local task existent on EARTH.ADA that is 
SCREEN. 

Task SCREEN can be used for two main purposes: 

- Allow non host transputer nodes(MARS, PLUTO, 
SATURN, VENUS) to send output messages to the host PC screen. 
This can be done by setting an appropriate message code that 
can be interpreted by task SCREEN that can print the desired 
Cubput 25 a resuli. 

- Accumulate statistics about the AUV_ flow 
Simulation. For instance, task SCREEN accumulates the total 
execution time and the number of iterations of task 
VEHICLE _SYS that can be used to calculate the average miges 


execution time. 
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Figure 3 illustrates the use of the HOST _LAYER by the 
program EARTH.ADA. The messages are read from the input 
channel(Mars2Earth) by the main program and sent to the 
circular buffer implemented by task EARTH_QUE. From there the 
messages are sent through procedure SEND _ IT _FROM_EARTH to task 
SCREEN that outputs information to the PC screen. 

3. THE COMMUNICATION LAYER PACKAGE 

The communication layer is the software that manages 
the communication with external nodes by non host 
transputers(MARS, PLUTO, SATURN and VENUS). This layer makes 
implementation of Ada multitasking in the transputer network 
to be location invariant because messages are sent from task 
to task by using the same communication primitives independent 
of the task location in the transputer network. It is 
implemented by the generic package COMLAYER enclosed in 
Appendix B. It should be noticed that, since the package 
HOST _LAYER does not have a message traffic handler like task 
INOUT on package COMLAYER, none of the application tasks 
should execute on EARTH. 

The package COMLAYER encapsulates tasks INOUT and QUE. 
These tasks are described as follows: 

a. TASK INOUT 

This task accepts messages from either the main 
program(external messages arriving at a node) or from local 


tasks (messages going to other nodes or even messages going to 


iy 


READ_OR_FAIL 
from INPUT CHANNEL 


ye 
/ 


MAIN PROGRAM 





Figure 3: Host layer used by EARTH 


other tasks in the same node). The function WHERE_IS that is 
declared in package COMMON, enclosed in Appendix B, is called 
and returns the destination node of the message. If the 
destination node is the local node the message will be sent to 
the task QUE that is responsible for the local message 
distribution. On the other hand, if the message destination is 
an external node it will be sent to this node through a 


communication channel. The INOUT task also chocsesuea 


Ie 


communication channel to be used depending on the routing 
strategy used for the network communication. 

There are four possible routing strategies that can 
be used with the network topology shown in Figure 2 that are 
declared in the package COMMON: 

- Counter-clockwise ring direction(CNT_CLK_RING) - 
ims aS the approach that was used in the first 
implementation. The messages are always sent in the direction 
MARS ->PLUTO->SATURN->VENUS->MARS. 

- Clockwise-ring direction(CLK_RING) - The messages 
are always sent in the direction MARS->VENUS->SATURN->PLUTO- 
>MARS. 

- Multipath(MULTI_PATH) - Chooses one output 
Brenna! aeeeraicomeeameng all Geossible lower cost soucpuc 
channels to a destination processor. The package RANDOM, 
enclosed in the Appendix B, was extracted from [ALSYS 90] to 
generate random numbers. This routing strategy is based on the 
multipath routing technique for a store-and-forward network 
layer implementation and is described in [TANENBAUM 89]. The 
lower cost output channels were obtained by inspection of 
Potgure 2 taking into account the number of hops between the 
nodes. The shortest path algorithm due to [DIJKSTRA 59] can be 
used to compute the shortest path between two nodes for more 
complicated networks. This algorithm is described in 


[TANENBAUN 89]. 
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- Best path(BEST_PATH) - This technique is suitable 
for hypercube networks. The network formed by the nodes MARS, 
VENUS, SATURN and PLUTO in Figure 2 is a simple hypercube of 
order 2. The algorithm always chooses the output channel that 
eliminates deadlock among the lower cost channels. This 
routing approach is based on algorithm A described in [TZENG 
91]. The output channel is chosen by taking into accountmen 
numbers that identify the processors(node addresses) in a 
hypercube. The relative address of the message source node to 
its destination node(the relative address of two nodes, say x 
and y, is the bitwise Exclusive-or of their addresses, x XOR 
y) is employed to choose the best channel to send the message. 
This algorithm eliminates deadlock by avoiding the formation 
of cycles by the routing paths. 

The package COMMON declares all routing tables that 
are used by these routing techniques. These tables must be 
generated by dedicated programs using the four approaches 
mentioned. It can be noticed that the routing tables are 
highly dependent on the topology used. Therefore, they mucmaae 
recalculated whenever there is a change in the topology. Some 
of them are even useless for certain topologies. For instance, 
it does not make sense to use a ring for an hypercube of order 
greater than two or for a mesh with a larger number of 
ELanepucers.. 

Looking forward to further expansion joc 


employed network, it can be noticed that MULTIPATH seems to be 
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the best alternative for MESH topologies while BEST PATH seems 
to be the best for HYPERCUBE topologies. 

Task INOUT needs to be initialized with the 
following data: 

- SITE - Informs the identification of the current 
node processor. 

- SEND_ARRAY - Array of type CHANNELS.CHANNEL ARRAY 
that must contain all output nodes used by this node 
processor. For each transputer node we can have up to 4 output 
channels that are declared in the node processor main program. 
The package CHANNELS contains all communication primitives 
that are offered by the Alsys Ada compiler system to run a 
multitransputer program(ALSYS 90]. 

- SEND_TABLE - Table of type OUT_TABLE. The type 
OUT TABLE is defined in the package COMMON. It is an 
unconstrained array(PROGRAMS range<>, NATURAL range<>) of 
BOOLEAN. The PROGRAMS range is constrained to the range of 
node programs MARS..PLUTO(MARS, VENUS, SATURN and PLUTO). The 
NATURAL range is constrained to the number of output channels. 
The BOOLEAN content of SEND TABLE(DESTINATION PROGRAM _ INDEX, 
OUTPUT CHANNEL INDEX) has the following meaning: 

.TRUE - OUTPUT_CHANNEL_INDEX points to a valid 
output channel that may be used for sending messages to the 
destination program pointed by the DESTINATION _PROGRAM_INDEX. 

. FALSE - The SOuepue elntstpupuicill pointed by 


OUTPUT CHANNEL INDEX is not a valid channel to be used for 
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sending messages to the destination program pointed by the 
DESTINATION PROGRAM INDEX. 

The main entry points defined for task INOUT can be 
seen aS communication primitives offered to the main node 
programs and to the tasks belonging to them to make 
multitasking in a transputer network location invariant ese 
mentioned entry points are described as follows: 

- INCOMING - It is called by the main node program 
to pass a message just arrived from an external node. 

- SEND - It is used by local tasks either to send 
messages to remote tasks(tasks located in external nodes) or 
to send messages to other local tasks. It is emphasized here 
that the local task does not have to worry about where the 
destination task is located and this feature makes the task’s 
communication location invariant. Communication transparency 
is provided because the same primitives are used to express 
both remote and local communications. 

b. TASK QUE 

This task implements a kind of QUEUE that is a 
circular buffer. It is called from task INOUT that passecmaae 
message to be distributed locally. This message is placed in 
the circular buffer and waits for its time of delivery. The 
messages are delivered in order of arrival but, if 4 
rendezvous with the receiving task cannot be established, this 


message loses its opportunity to be delivered and has to wait 
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Pjeesreniexr Cinenlar butter scan to have another opportunity. 
Therefore, the order of delivery of the messages is not 
guaranteed to be the same as the order of arrival in the 
Secular buiter. 

An instance of the procedure that issues entry calls 
to the local tasks(SEND_IT) must be created on each processor 
node. This procedure is not transparent in relation to the 
allocation of tasks on the transputers. This happens because 
the user should know which tasks are allocated to each 
transputer to write each specific node procedure to generate 
SEND_IT. 

Figure 4 shows the relationship between the tasks 
in one node program when using the communication layer. It can 
be noticed that the task WAITING that was used in the first 
implementation{ RICHMOND se] was eliminated from the 
communication layer. Task WAITING uses one additional queue 
that may be employed between INOUT and QUE tasks and was 
eliminated because it was not really used by the communication 
layer. 

4. ADA IN A DISTRIBUTED ENVIRONMENT 

Several approaches can be applied for implementation 
of the ADA language in distributed systems. These approaches 
are reviewed by [ATKINSON 88] and the most important are 


summarized as follows: 
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READ from INPUT 
CHANNELS 


~ 


MAIN 
PROGRAM 


Wa 
A 
TO_QUE a SEND_IT 





Figure 4: Communication layer relation to the main program 


- Full ADA, Multiple Communicating Programs - In this 
case one separate ADA program is required for each processor 
node that composes the transputer network. These programs use 
basic communication primitives to communicate with each other. 
This requires knowledge of the underlying network by the 
programmer but leads to a faster implementation. The main 


disadvantages of this approach are that programs must be 
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rewritten when the network is changed and that ADA semantics 
regarding multitasking is not fully implemented. 

- Full ADA, Single Program - The program is written as 
only one ADA program. This approach fully implements the ADA 
semantics and, aS a consequence, it is highly portable. The 
peoblems of partitioning, task allocation and task 
distribution must be solved by the compiler. Unfortunately, 
compiler technology for distributed programs has not solved 
these problems in a satisfactory way. In addition, it requires 
a fairly complicated communication software system to support 
the full ADA semantics across the network. 

- Non-Uniformly Restricted ADA, Single Program - In 
this case, the ADA semantics is fully implemented within the 
limits oe abstract entities called Vara Wel) nodes. 
Communication across the boundaries of the virtual nodes is 
achieved by remote rendezvous. 

The implementation of the communication layer employs 
a solution based on the Full ADA Multiple Communicating 
Programs approach because it employs one ADA program for each 
node processor. In addition, communication between these 
programs is achieved by basic primitives offered by the 
package CHANNELS. 

In the first implementation of the communication 
layer, the remote rendezvous is simulated by task QUE at the 
receiving node(CALLEE) that sends an acknowledge message to 


the task origin (CALLER). The origin of the message will not 
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proceed until it gets the acknowledge message from the CALLEE. 
In fact, this is the only way to go when working with the 
following types of entry calls[ATKINSON 88): 

- Entry call that has out parameters. It works as a 
remote subroutine call so that the CALLER has to wait for the 
CALLEE return before proceeding. 

- Conditional entry calls - A conditional entry eau 
issues an entry call that is then canceled if a rendezvous is 
not immediately possible[VOLZ 85]. Due the time delays in the 
remote communication the CALLER may cancel an entry call when 
the CALLEE is still able to accept the entry call. 

- Timed entry calls - A timed entry call issues an 
entry call that is canceled if a rendezvous is not Stange 
within a given delay[REYNOLDS 83]. There is a problem of 
interpretation in where to consider the time delay. [© camme 
considered from the CALLER or from the CALLEE time reference. 

The acknowledge messages employed in the first version 
of the communication layer were avoided in the new version due 
to the following reasons: 

- These messages may lead to a deadlock situation in 
case of using MULTIPATH or BEST_PATH routing strategies. This 
problem seems to be related with the cycle formed by tasks 
INOUT and QUE when INOUT may send a message to QUE at the same 
time that QUE is sending an acknowledgement to INOUT. 

- The AUV tasks can communicate by using simple 


messages without requiring an immediate return from the 
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destination. Timed entry calls are issued by task QUE in the 
CALLEE node. Therefore, it does not seem to be a big problem 
if the CALLER task proceeds before the rendezvous with the 
CALLEE has been established. After all, if the CALLER task 
depends on results of an action to be taken by the CALLEE 
task, it will suspend in an accept statement waiting for the 
required results. Thus, the new version of the communication 
layer does not implement the Ada rendezvous in a peer to peer 
sense but rendezvous is used between the tasks that implement 
the communication layer and the local node tasks. 

- The acknowledge messages contributed to the total 
overhead of the communication layer. Since for every message 
there is an associated acknowledge message, it practically 
doubles the communication load. 

5. DEADLOCK AVOIDANCE 

There are at least four potential deadlock situations that 
may occur in distributed systems leading to a general blocking 
Situation: 

- Asynchronous use of the communication channels - For 
instance, in Figure 2, consider the case where VENUS attempts 
to send a message to MARS at the same time that MARS attempts 
to send a message to VENUS. Both processors are using the 
shortest path links to send their messages. Both processors 
are using the primitive WRITE of the package CHANNELS that is 


not preemptive. Therefore, if none of the transputers gives 


27 


up, then the programs will deadlock. If this problem happens 
with the communication layer, the situation may be recovered 
because the WRITE primitive is called from task INOUT and the 
READ primitive is called from the MAIN program on each node. 
Since the tasks are switched on each processor node, it is 
possible that the WRITE primitive in a node coulda 
synchronized with a READ primitive of the other node due the 
random nature of the task activation mechanism, however, this 
1s not guaranteed. The program user should then enforce the 
synchronization when using the primitives READ and WRITE to 
ensure that this situation will never happen. In this 
communication layer absence of (déeadiise is guaranteed by 
using Best Path or Ring routing strategies. The Multipath 
routing strategy is not guaranteed to be deadlock-freeé due its 
random mechanism. Another solution is to use the READ _OR_FAIL 
and WRITE_OR_FAIL primitives of the package CHANNELS. These 
primitives employ a preemptive time-out that gives up the use 
of the primitive if it cannot succeed within 4 speciired 
period. This solution may cause indefinite postponement that 
is also undesirable. 

- Lack of the circular buffer space - For instance, if 
MARS is trying to send a message to PLUTO but this processor 
does not have room in its circular buffer to hold the new 
message, then PLUTO tries to send a message to another 
processor to free space for the incoming message. Considering 


that all other processors are also with their circular butters 


26 


Pwd deadlock Situation will occur. This problem is avoided 
byeehoosing a Sultable size for the circular buffer in task 
QUE of the communication layer to accommodate the traffic 
generated by the flow simulation. It can be noticed that an 
Eecescstve Size of the circular buiter implies waste of memory 
Space as well as higher overhead for the communication 
iaver[ RICHMOND 91]. A circular buffer of size 20 was enough 
for all application flow simulations in this thesis. 

- Asynchronism between tasks - Considering two tasks 
A and B, if task A issues an entry call to task B at the same 
time that task B issues an entry call to task A, deadlock 
Situation will occur. One way to prevent this kind of deadlock 
is to avoid cycles in the directed graph that represents the 
task flow to be simulated. For the cases where cycles cannot 
be avoided it is required that all tasks in the cycle get 
their inputs before trying to send their outputs to obtain an 
overall cycle synchronization. Another alternative is to use 
preemptive entry calls(conditional or timed entry calls) for 
the rendezvous implementation. This solution has_ the 
inconvenience of indefinite postponement. Therefore, the 
programmer should enforce task synchronization to avoid this 
kind of deadlock. 

- Asynchronism of messages arriving in one task - One 
Single task may have several entries accepting messages from 
different tasks. These messages need to be synchronized to 


avoid potential deadlocks due different message arrival 
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times. Programs MARS, PLUTO, SATURN and VENUS use selective 


non-ordered loops to avoid this problem. 


B. AUV SIMULATION FLOW 
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Figure 5: AUV simulation flow 


Figure 5 shows the Autonomous Underwater Vehicle(AUV) 
Simulation flow that was used in the original implementation 
and in the evaluation of the communication layer modification 
reported in this document. A detailed description of the AUV 


flow can be found in [RICHMOND 91]. 


30 


Table X contains the execution times that are used for all 
tasks of the AUV flow simulation. Each value is only an 
estimated execution time based on the complexity of the 
Semponent task and may not represent the real execution time. 
Task TIMER is not included in TABLE X because it is the task 
that controls the interval of repetition to be used by the AUV 
simulation with little overhead to the total execution time. 

The AUV simulation flow is implemented by programs 


MARS.ADA, PLUTO.ADA, SATURN.ADA and VENUS.ADA, and the package 


Table X: AUV FLOW - TASK EXECUTION TIMES 


akey ue 
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COMMON.ADA. These programs are enclosed in Appendix B. 
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C. DEADLOCK RELATED TO THE AUV SIMULATION FLOW 
The following measures are used to avoid deadlocks when 
using the communication layer for the AUV implementation: 

- The AUV flow shown in Figure 5 has multiple cycles 
and all of them start and finish at task VEHICLE SYS) Diiem@ahe 
data dependency to task AUTO PILOT and the time control 
imposed by task TIMER, the task VEHICLE SYS cannot issue entry 
calls until it accepts VS_ORDERS from AUTO_PILOT and GOUiwe 
task TIMER. This feature ensures the task synchronization that 
avoids the deadlock. 

- The acknowledge messages that were used in the 
original implementation were removed in the modified 
implementation because they were leading to deadlock for 
certain routing strategies. 

- Task QUE employs a circular buffer to store the 
local messages and the procedure SEND_IT to distribute them to 
local tasks. An instance of the procedure SEND _ IT is generated 
on each node. This procedure ensures a preemptive scheme of 
message delivery. The procedure issues an entry call, if the 
call cannot succeed within a given time delay, it is canceled 
and the message is skipped in the circular buffer. It has to 
wait for the next circular buffer scan to have another 
opportunity of being delivered. All instances of SEND IT use 
zero delay for the timed entry call. This delay is important 
because it has the effect of suspending the task when the 


rendezvous with a local task cannot be established right away. 
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-S figure 4 shows another kind of cycle that is 
Gemposed by tasks INOUT, QUE, and the local task. Each cycle 
is formed by the following task sequence: task INOUT -> task 
QUE -> local task -> task INOUT. These potential deadlocks are 
avoided because the local task only issues an entry call to 


INOUT after accepting all entry calls from task QUE. 


D. CHARACTERIZATION OF COMMUNICATION PERFORMANCE 

Figure 6 shows the Gantt Chart for the execution of the 
AUV flow of Figure 5 on the transputer network formed by 
processors MARS, PLUTO, SATURN and VENUS of Figure 2. This 
chart also shows the static task allocation that was used for 
the AUV flow simulation. 

The static allocation is defined by the declaration of the 
type TASKS and the function WHERE_IS in package COMMON and by 
the instances of procedure SEND_IT on each node. 

It can be seen from Figure 6 that the time spent by the 
AUV flow is lower bounded by 0.35 seconds that is the sum of 
the execution times of the tasks that compose the longest 
path PaOlemaske (SMTChE Svominertqure 5(VEHICLE SYS, SONAR, 
AVOIDANCE, EXE MISSION, GUIDANCE and AUTO PILOT). This minimum 
cost does not take into account the communication overhead. 

Therefore, the maximum theoretical speed-up that can be 
achieved with this data-flow considering that it cannot be 
pipelined due to existent data dependencies is 0.43/0.35=1.23. 


The value of 0.43 seconds is obtained by adding all task 
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Figure 6: Gantt chart for the AUV flow execution 


execution times giving a time that is equivalent to the time 
needed to run the flow in a single processor. 

Due to the AUV flow limitation, the best speed-up that can 
be achieved is much lower when compared with the possible 
linear speed-up for 4 processors(1.23 < 4). This happens 
because the AUV flow is not parallel enough to exploit all 
potential parallelism of the 4 transputers. This fact can also 
be noticed by the low utilization of the processors as shown 
Ip Figure 6. 

Table XI shows the best results that were achieved for the 
AUV flow execution time with different routing strategies. 

From Table XI it can be noticed that the maximum 
communication overhead obtained is 23.1 msec given  Syeen 
counter clockwise ring POU cing strategy(0.373lsecs- 


0.35secs=23.1ms). The minimum communication overhead obtained 
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Table XI: EXPERIMENTAL EXECUTION TIMES FOR THE AUV FLOW 


Routing Counter 
strategy clock- 
wise 


ul, phe 


Execution 
time(s) 





is 17.5msec given by both multipath and best path routing 
strategies(0.3675secs-0.35secs=17.5 msec). Therefore, an 
improvement is achieved by using different routing strategies 
than the counter clockwise ring routing strategy even for 
transputer networks with very few components, as in the case 
of Figure 2. This difference tends to be bigger when using 
more complex transputer networks. 

Considering the communication overhead for the AUV flow of 
9 hops per iteration and an approximated message size of 94 
bytes, we can estimate the bandwidth for the best path routing 
Ereearegy((94*6*9)/(0.0175)=386.7 Kbps). 

THE WEdGeOrs that can contribute for the communication 
Svernead are: 

- Size of the message; 

- Interprocessor distance in number of hops; 

- Transputer link communication channel bandwidth(10 to 20 
Mbps for the INMOS T8000); 

- Frequency (ong the main AUV flow loop 
Meeration.(1/0.37=2.70 Hz); 

-~ Task switching(executed every lms[ALSYS 90] with an 


overhead of about 20 microseconds per switch); 


a 


- Circular buffer scan delay(queve delay); 

- Overhead due the comparisons used by the case statement 
in function WHERE IS of the package COMMON; 

- Overhead due the comparisons used by the case statements 
used by procedures SEND_IT on each processor; 

The size of the message and the interprocessor distance in 
number of hops are the factors that have a major influence on 


the communication overhead. 


E. CHANGES REQUIRED TO MEET NEW PROJECT SPECIFICATIONS 

Unfortunately, the scheme supported by the Alsys ADA 
Compilation System is very inflexible to changes in the 
network topology. Therefore, at least the following 
modifications are required to adapt the communication layer 
software to different topologies: 

- Existent OCCAM harnesses must be modified to reflect the 
new network topology so as to include the allocation of extra 
communication links to extra processors. 

- Two extra OCCAM harnesses and an extra ADA program have 
to be produced for each additional transputer node to be 
included in the network. 

- The package COMMON must be modified in order to update 
the routing tables. 

- The initialization messages that are used by programs 


EARTH.ADA, MARS.ADA, PLUTO.ADA, SATURN.ADA and VENUS.ADA to 


36 


Setsche routing Strategy and the period of repetition of the 
simulation flow must be modified. 

In addition, in order to simulate different applications 
the following changes must be implemented: 

- The types TASKS and ENTRYS in package COMMON must be 
redefined. 

- The SEND_IT procedures in programs MARS.ADA, PLUTO.ADA, 
SATURN.ADA and VENUS.ADA must be rewritten to reflect the new 
task entry points. 

-~ The body and specification of the tasks in programs 
MARS .ADA, PLUTO.ADA, SATURN.ADA and VENUS.ADA must be modified 


in order to represent the new allocation. 
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III. TASK ALLOCATION 


A. PROBLEM DEFINITION 

The problem of task allocation can be defined formalipaiae 
using graph theory. The application flow can be réepréséngeaua, 
a graph G, = (V,,E,), where V, i8 “a Se "or = 7emames 
representing tasks V,={t,,t,,...,€,} amd BE, 16 a sé€t of Game) 
edges representing the intertask dependency. Data structures 
can be used in the vertices to hold task information such as 
execution times, deadlines and repetition rates, and in edges 
to hold communication costs such as the size of the message. 
Figure 5 shows an example of graph representation of the AUV 
Simulation flow. 

The network topology can also be represented by a graph G, 
= Gas) 5 where Vp is a set of vertices representa 
processors V,={Py,Pa,-++1Py} and 3S is a set of links 
representing communication channels. Data structures can be 
used in the vertices to hold information about the processor 
such as memory capacity and performance in MIPS, and the edges 
can hold information about the communication channels such as 
bandwidth in Mbps. Figure 2 shows an example of graph 
representation of the transputer network used in this thesis. 


The problem of task allocation usually can be seen as a 


mMany-to-one mapping, as shown in Figure 7. The problem can be 
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stated as how to generate an efficient mapping from N tasks to 
M processors to minimize the intertask communication costs, to 
balance the load utilization on the processors, to meet 
individual task deadlines or to minimize the total response 


time of the simulation flow. Task allocation is a 


TASK ALLOCATION 





Figure 7: Task allocation as a mapping Problem 


combinatorial problem whose search space S(number of possible 
solutions) for a problem with N tasks and M processors can be 


calculated by the following equation: 


S=MN (1) 


ony 


An objective function must be defined to search for a 
solution in the space S. This function must establish the main 
goal of the problem because some of the potential goals of the 
optimization may be contradictory. For instance, the best 
solution to minimize interprocess communication costs may lead 
to a load unbalanced system. For this thesis, the objective 
function tries to minimize the response time for the entire 
task flow and the number of processors used. Some 
Simplifications are assumed to this problem such as no 
requirements to meet individual task deadlines, application 
task flow pre-sorted in topological order, only periodic tasks 
considered in the application flow, all tasks executed with 
the same rate of repetition ,and deterministic execution 
times(the worst case task execution time is employed). The 
latter simplification is unrealistic because task execution 
times can have large variances, but at least it makes the 
static allocation of tasks to processors possible[QUINN 87]. 

Even with the simplifications mentioned above, this 
problem is classified as NP-hard, meaning that it is unlikely 
that a polynomial-time algorithm could always find an optimal 
allocation given an arbitrary task flow graph. As an example, 
consider the case where the number of processors is equal to 
4 and the number of tasks is equal to 16. The search space as 
calculated by Equation (1) results 4,294,967,296 possible 
solutions. If an exhaustive search were used for this problem 


with an assumed cost of 0.lmsec per search the complete search 
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CRITICAL PATH 


T1, 72, 79, T4, T5, T8 TASKS 
E1, 2, £3, 64,65,68 EXECUTION TIMES 
CW). =COMNUNICATION COST 


MINIMUM THEORETHIGAL RESPONSE TIME = E1 + E93 + ES +68 = 11 





Figure 8: Minimum response time 


would be completed in approximately five days. Thus, even 
small instances of the problem are hard and its complexity 
grows exponentially. 

Therefore, heuristics are required to reduce the search 


Space leading to near optimal solutions in polynomial time. 


B. DESCRIPTION OF THE HEURISTIC 
A constructive assignment of tasks to processors is 


employed to obtain a near to optimal solution for the minimum 
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response time of an arbitrary application task flow with a 
minimum number of processors. Different aspects are considered 
in this scheme. 

First, we notice that the best solution that can be 
achieved is lower bounded by the sum of the execution times of 
the tasks that are in the critical path, as illustrated in 
Figure 8. This feature is independent of the number of 
processors used in the network. Equation (2) formalizes how to 


compute the minimum theoretical response time R as a 


tmin 
function of the task execution times E, for every task gem 


the critical patn. 


Re Ei (2) 


The real minimum task flow response time for a network of 
processors is increased mainly by two sources that are the 
delay caused by task dependencies and the task communication 
overhead. 

Task dependencies can usually be minimized by using more 
processors on the network to match the parallelism on the 
network with the parallelism on the task flow. This solution 
is not always satisfactory because increasing the number of 
processors may lead to an underutilized system. Communication 
overhead can be minimized by allocating tasks with high 
communication costs on the same processor and by having an 


efficient communication system. 
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The imEemum response time Ry can be calculated as the sum 


of its minimum theoretical R the overhead due task 


tmin 
dependencies O, and the overhead due the communication O, as 


stated in Equation (3). 


R,=R, +030, (3) 


Diemevennedd sce medsk dependencies O07 1s independent of 
the communication system. It happens because a child task 
cannot start execution before all its parent tasks finish 
execution. 

Picsovwcniedc que LNe comnintcation system sO is a function 
of several factors such as message size, interprocessor 
distances, bandwidth and queueing delay. 


There is no possible alternative to decrease R for a 


tmin 
given task flow because this is an intrinsic feature of the 
task flow. It can only be changed by modifying the task flow. 

Two other parameters that are frequently used to evaluate 
the performance of parallel computers are the speed-up and the 
throughput. The speed-up is defined as the ratio of the total 
execution time of the task flow on an uniprocessor computer to 
the execution time on the parallel computer. The throughput is 
a measure of the number of computations of the total task flow 
in a given time interval. 


The total execution time of the application task flow on 


Bmeaprocessor computer T,. can be calculated as the sum of 
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the task execution times E, for every task 7 on fea 


application task flow, as stated in Equation (4). 


Tani 2; (4) 


Assuming that the application task flow cannot be 
pipelined due to task dependencies. Then, the speed-up Sp can 


be calculated by Equation (5); 


67 ue (5) 





As our heuristic has also a goal of minimizing the number 
of used processors, we can estimate what is the minimum number 
of processors to be tried in the search for a solution. We 
know that there is upper bound for the speed-up that can be 
calculated as in Equation (6) but there is also an upper-bound 
for this parameter imposed by the number of processors 


employed in the network M as shown in Equation (7). 


3¢ et 
——— (6) 
P 
Rein 
SsM (7) 


From (6) and (7) we can derive a lower bound to the number 


of processors to be used as shown in Equation (8). 
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M> a (8) 
Cnin 
Moie@tpor-editmn lomeOmmpemadpplteduin the heuristic 15 to 
weomomteget her all tasks Chat compose the critical path and 
Pmelccadreuelis cluster On Easks to the same processor p,. Then, 
Temowiccace the Lenmalning tasks in processors p, to p_. From 
Picdelonm( ij wemcan noclee that this rule reduces the search 
peeee. TOR simistdice, tt) these are N, tasks on the critical 
Peawieout Of the total of N tasks om the task flow the new 


Beamch space 5. can now be calculated by Equation (9). 


W 
Shae (N-N,) a (9) 


A second rule should minimize the total overhead: imposed 


to the response time O described in Equation (10). 


total 
ern eee (10) 


This rule is based on a pair-wise examination aNe 
communication tasks[RAMAMRITHAM 89]. Every pair of tasks must 
Semecxamined according to one heuristic function. This 
Meuristic function must reflect the utility of putting one 
particular pair of tasks together on the same processor or on 
separate processors. This function depends on Ci; that is the 
communication cost between two tasks T,; and T; and) on the 


exeeurton times of these tasks, E,. and E, respectively. 
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Equation (11) shows how the function Haj balances the influence 


of these factors by tunable constants K, and K,. 


Ho Romer 


4a (11) 
j 2 SE ne 


The higher the value of this heuristic function; eeeme 


higher is the utility in putting this pair of tasks on@ene 


Construct the task flow graph; 

Determine the critical path and the minimum 
number of processors to be used; 

Allocate cluster of tasks in the critical path to 
processor P1; 

For every pair of tasks [i,j} 
Calculate heuristic function h(i); 

Sort the values of h(i) in ascending order; 

[ Allocate tasks to processors P2 to Pm */ 


While not all tasks are allocated loop 
Pick not allocated task pair {ij} with the lowest h(i); 
Allocate Ti and Tj to different processors; 
Pick not allocated task pair {k,l} with the highest h(x); 
Allocate Tk and TI to the same processor; 

end loop; 





Figure 9: Pseudocode for the constructive assignment 


same processor. On the other hand, its lower value indicates 
more advantage in putting them on separate processors. The 
communication cost C.; will be assumed zero when there is no 
precedence relationship between tasks T, and T;. Therefore, 
tasks with no precedence relationship tend to have a lower 


value of Hi reflecting a tendency to go on separate 
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processors. This is a good consequence because tasks with no 
precedence relationships are good candidates for parallel 
execution. 

Ineaceditaen, the term that 1S imyversely proportional to 
fhewscum of the €xecution times =. and E, takes into 
consideration the following aspects: 

ee ew OWer serie Sum) Of —&- and E, the lower is the 
advantage obtained by running them in parallel even if they 
do not present a precedence relationship. 

=eOnmultc sol Nerenand, che higher Ehersum of B. and E;, the 
better it is to have them separated because it balances the 
mBeecessor utilization. Also, tasks i and } are more likely to 
have some overlap on their execution times. 

The basic scheme employed in the task allocation is 
summarized in Figure 9. 

The sorted vector h(i,j) is searched from top-down and 
from bottom-up to allocate tasks that are not on the critical 
path. Tasks with lower h(i,j}) values have priority to be 
allocated in separate processors while tasks with higher 
h(i,j) values have priority to be allocated on the same 
processor. The least used processor criterion is used to 
determine which processors to employ for the pair allocation 
to balance the load on the network. 

iaoltow ti isean example cf Calculation of the heuristic 
Peecor fi(i,}) for the task flow of Figure 8 assuming K, = 0.5, 


ime 0.5, atid all communication costs equal to 1.0. 
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Considering the exampie of Figure 8, we obtain] Tae 


and R = 11. By using Equation (8), we get that M should be 


tmin 
greater or equal 15/11=1.36. (Thererenmce two or more 
processors are required to achieve the best speed-up. 

From Figure 8, we know that the critical path is composed 
Of Bedcks 0 


T,, T, and T,. Thus, this set of ~tCackamiee 


qr 
allocated to processor p,. 

This example is too simple to fully demonstrate how the 
constructive assignment of tasks works but at least we can 
follow its search mechanism. Initially, the heuristic examines 
the pair of tasks {T,,T,}; we should put T, and T, in séparaue 
processors and T; is already allocated to p,. So, we allocate 
T, to processor p,. Then, the heuristic examines the palimige 
tasks {T,,T,}; we should put T, and T, om the same procesi@n 
and, T, is already allocated to p,, so we skip this pairs 
Finally, the heuristic examines the pair of tasks {T.,,T,}. We 
should put T, and T,; in separate processors. T, is already 
allocated to p,, so we allocate T, to processor p, and we are 
done because all tasks are allocated. If the allocation were 
not complete then the following sequence of pairs would be 


searched( {5,6} ,13,6),41, 21344, 537. 
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Hable KIL: HEURISTIC FUNCTION 
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C. LIMITATIONS OF THE CONSTRUCTIVE ASSIGNMENT 

The constructive assignment heuristic presented in the 
last section has some limitations that recommend the use of an 
iterative improvement to increase the quality of the task 
eltocation. 

The main limitation is that the heuristic does not take 
into account the interprocessor distances because these 


distances are only known after the allocation is completed. 
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The communication costs only consider the relative sizes of 
the task synchronization messages. 

In addition, the heuristic function does not providema 
completely ordered set of task pairs. We can notice in table 
XII that there are many pairs of tasks with the same value of 
heuriseve function hia ay. 

An improvement of the task allocation can be obtained by 


applying the approach described in Figure 10. 


For every processor node Pi on the current allocation loop 
Calculate the schedule of execution using task 
precedences and get the latest execution times; 
Calculate the communication overhead using 
communication costs and the interprocessor 
distances; 
end loop; 
Calculate the estimated maximum response time for the 
current allocation(AT current); 
For Kin 1..NUM loop /* Repeat NUM times */ 
Change the current allocation using a pair-wise 
interchange of tasks and get a new allocation; 
For every processor node Pi on the new allocation loop 
Calculate the schedule of execution using task 
precedences and get the latest execution times; 
Calculate the communication overhead using 
communication costs and the interprocessor 
distances; 
end loop; 
Calculate the estimated maximum response time for the 
new allocation(ATnew); 
if ATnew < ATcurrent then 
Current allocation := New allocation; 
end if; 
end loop; 


Figure 10: Pseudocode for task allocation improvement 





Equation Cie) describes how 1S) calculate the 
communications overhead on processor 1(0.,) as a fumctronges 


the edge communication costs C.; and the interprocess 


a0 


communication distances D;; fOr evemyerask 1 in processor 1 and 


any task j in other processors. 


Shag ar Ds; (12) 


The pair-wise exchange of tasks first divides the set of 


tasks in two sub-sets of tasks by using a random number 


Table XIII: PACKAGES AND THETR FUNCTIONS USED IN 
ALLOCATION 





= 







PACKAGE STATUS 


FUNCTION 





Generate 
random 
numbers 


Wea 1G) bad seereay N/A iol ono 
Output 


QUEUES _2 User QUEUES2.ADA Generie 
Defined Queue 

abstract 

data type 


Library 












DISCRETE SET User DISET.ADA Generic 
Defined Discrete 
Set 
abstract 
data type 


SORT ADT User SORT.ADA Generic 
Defined Sore 
routines 










GRAPH2 ADT User GRAPH2.ADA Generic 
Defined Directed 
Graph 
abstract 
data type 


3) IL 


generator. Then, it exchanges every item in the first sub-set 
with the corresponding item in the second sub-set. This 
exchange should only be performed if neither task is ecnjeme 


ecripieal path 


D. ALLOCATION IMPLEMENTATION 
A general overview of the heuristic described in the 
previous section is illustrated in Figure 10. The complete 


scheme is implemented by the main procedure STATICAL in file 


OPERATIONS 
INSERT_NODE 
INTERSER_EDGE 


SET_WAITING 


DEPTA 
FIRST_SEARCH 


OPERATIONS 
SELECT_SORT 
EXCHANGE_SORT__.. 


STANDARDINSERT_SORT 
ELEMENT gs 2 


Qs_a 
MERGE_SORT 





Figure 11: User defined packages 


STATICAL.ADA. Table XIII shows the packages that are used by 


this program. The packages QUEUES2.ADA, DISET.ADA, SORT.ADA 
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and GRAPH2.ADA are enclosed in Appendix C. The separately 
compiled procedures CONSTRUCT_TASK FLOW, CALC_HEURISTIC, 
ALLOCATE, SCHEDULE and IMPROVE are called by the main program 
STATICAL. 

The files STATICAL.ADA, CTFLOW.ADA, CALHEU.ADA, ALLOC.ADA, 
SCHED.ADA and IMPROVE.ADA are enclosed in Appendix D. 

Figure 11 shows the basic operations offered by each one 
of the abstract data types as defined in the generic packages 
QUEUES2, DISCRETE SET, GRAPH2_ADT and SORT_ADT. These packages 
are ADA versions of the MODULA-2 implementations described in 
[STUBBS 87]. 

Package DISCRETE SET implements the SET abstract data type 
that is very useful in task allocation. For instance, each 
node allocation is a SET of tasks that run on a particular 
processor node. 

Package GRAPH2 ADT implements the directed-graph(DGRAPH) 
abstract data type that is used to represent the application 
task flow. 

Package QUEUES2 implements a FIFO queue that is used as an 
eoxtliary data structure for the calculation of the critical 
path of the task flow. 

Package SORT_ADT implements several schemes of SORT. A 
Week sort aligorithm(9S 3) is employed to sort the heuristic 
meceor h(i,j). 

Package RANDOM is employed to generate the two clusters of 


tasks that are used in the iterative pair-wise exchange task 


58) 





Figure 12: STATICAL data flow diagram 


for the allocation improvement. 

Figure 12 shows the data flow diagram of the main program 
STATICAL. This program has the following basic structure: 

- Initially, it calls the procedure CONSTRUCT TASK IEaere 
This procedure reads the data file describing the application 
task flow, and then generates a directed task flow graph using 
the operators INSERT NODE and INSERT EDGE of the package 
GRAPH2 ADT. In addition, it counts the number Of taskowage 
calculates the critical path for the task flow. 

- It calls the procedure CALC HEURISTIC that caleuWaees 
the heuristic function h(i,j) for every pair of tasks {i,j} 


and then sorts the vector h(i,j) using a quicksort algorithm. 
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- It calls the procedure ALLOCATE that queries the user to 
DiGi elemmiumnIemNOonepmocessous to be used and then allocate 
tasks to the processors following the constructive assignment. 

- It calls the procedure SCHEDULE that calculates the 
schedule of execution on each processor. It employs an 
eiigeritnm that schedules tasks with lower identification 
numbers first. It is assumed that the input task flow had 
already been submitted to a topological sorting. 

- Finally, if the number of processors is equal to 4 it 
will call the procedure IMPROVE that enhances the task 
allocation using the iterative pair-wise interchange of 


tasks. 


EXAMPLE - FLOW WITH 6 TASKS 
NODE 1 


10 
1.0 
10 


1.0 
10 


1.0 
1.0 
10 


~eascopapaPney 


2 
1 
3 
1 
4 
1 
6 
2 
3 
6 
4 
6 
6 





Figure 13: Task flow input data file 


De! 


The task flow input data file must be specified using the 


commands NODE and EDGE. The command NODE must be followed by 


E19 =10ms E14 =40 ms 


© 


E19 = 20 ms 





Figure 14: 25-Task simulation flow 


the task identification number of type INTEGER and by the rae. 
execution time of type FLOAT. The command EDGE must be 
followed by the source and destination task identifiers both 


of type INTEGER and by the communication cost of type FEOATe 
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The first line of the file is not used because it is reserved 
for comments. Figure 13 shows one example of task flow input 
@ata file “for the flew described in Figure 8 with 
communication costs equal to 1.0. We can notice that an extra 
edge is placed between task T, and task T, to characterize the 


assumption that this flow cannot be pipelined. 


E. PERFORMANCE RESULTS 

1. APPLICATION FLOW WITH 25 TASKS 

The 25-task example of Figure 14 was simulated using 

the transputer network of Figure 2 to verify the robustness 
of the communication layer in relation to deadlocks with a 
more complex flow than the AUV flow and to evaluate the 
Gonstructive assignment heuristic. This flow is a modified 
version of the Air-Defense flow described in [TSUCHIYA 82]. 
The allocation for this flow considering all communication 
Beoec equal to 1-0, K, = 0.5 and K, = 0.5 is shown in Figure 
16. 

Table XIV shows the results obtained for this flow with 
different routing strategies: 

Table XIV: RESULTS FOR THE FLOW OF FIGURE 14 
Routing Counter 


SEraceoy clock- 
wise 


eal ioe} 


Execution 
time(ms) 





ae 


By running the program STATICAL we can ger tiac 1 7 eee 
ms and that the longest path is composed of tasks T,, Ts, Ts, 


Ty, Tage Toy, Tox; and T,, with R,,. = 280) mS Sanciy i, haem 


3.7464. Thus, by Equation (8) we should use at least 4 


processors. This program also gives Od = 45ms and Rtmin+Od = 





Figure 15: Task allocation for the flow of Piguresi4 


325.0ms when using 4 processors. Therefore, we should use 
more than 4 processors to drive the dependency overhead to 
zero. The communication overhead can be obtained by using the 
data in Table XIV that gives Oc = 377.43 —- 325.0 — 52.428 
The communication efficiency can be calculated by Equation 


(13) that gives Ec = 86.10 %. 
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R, +0 
ee ta 8 (13) 


2 Ree ORO. 


The processor utilization Up can be calculated by Equation 
(14). Table XV shows the utilization for every node processor. 
From this data, we can notice that the allocation scheme 
resulted in a load balanced system. 

dF: (14) 


_ 1ep 
Le R 





ie 


Table XV: UTILIZATION FOR THE FLOW OF FIGURE 14 


NODE PLUTO SATURN VENUS 


Up(%) 74.18 78.69 61.47 63.59 









Since we do not have automatic tools for changing the 
allocation on the network of transputers we will investigate 
how to improve the constructive assignment and how the 
allocation changes to reflect different communication costs 
using a simpler flow with 16 tasks. This simplification is due 
the amount of work required to change the allocation with a 
larger flow without automatic tools and does not imply loss of 


generality. 
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2. APPLICATION FLOW WITH 16 TASKS 
Figure 16 shows the task application flow that is used 
in this sub-section. It is an arbitrary task flow with several 
features commonly found in real applications such as task 
dependencies and threads of parallelism with £ork7 jem 
SEruUCrUrEes. 
a. CONSTRUCTIVE ASSIGNMENT WITH EQUAL COMMUNICATION 


COSTS 


E1l=10ms 


10,138 = 25 
£13 - 26 ms 


C13,16 - 1 
E16 = 46 mg E16° 16 ms 
T16 





Figure 16: 16-Task simulation flow 


Figure 17 shows the allocation generated by (stig 
COnstruchive assignment heuristic considering Bul IL 


communication costs equal to 1.0, K, = 0°3 anda 


4 
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EXECUTION TIME (ms) 
re Ce 1 Ng 





Figure 17: COonstruuctive. assignment with equal 
communication costs 


Table XVI presents the results obtained with this task 
allocation on the transputer network of Figure 1. 
Table XVI: RESULTS FOR THE CONSTRUCTIVE ASSIGNMENT WITH 
EQUAL COMMUNICATION COSTS 


Rewem¢ 
Strareqy 


| Execution 
time(ms ) 





Die iow ids Te e400 ms and ats lorigest path is 


composed by tasks T,, T,, T,, T,, and T,, with R = 125 ms 


tmin 
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Table XVII: UTILIZATION FOR THE CONSTRUCTIVE ASSIGNMENT 
ALLOCATION WITH EQUAL COMMUNICATION COSTS 


Up(%) 76.23 60.99 54.99 57.94 






resulting inet 7s = 3.28. With the allocation shown 


uni tmin 


figure 17, we get 0, = 20 ms and R,.+0, = 145 m5 
communication overhead can be obtained by using the data of 
Table XVI resulting in O, = 163.97-145.0 = 18.97 me ie 


communication efficiency, as calculated by Equation (13))e 





Figure 18: Improved task allocation with equal communication 
COSts 
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Bee -e0ces set. athe resulting processor utilization on each node 


processor is shown on Table XVII. 


b. IMPROVING THE ALLOCATION WITH EQUAL COMMUNICATION 

COSTS 

Figure 18 shows the task allocation generated by 
improving the Que ie jsuialst ll aivocat ion considering equal 
communication costs and by using 100 iterations of the 
iterative pair-wise tasks interchange algorithm. 

Table XVIII presents the results obtained with this 
task flow simulation on the transputer network of Figure 2. 


Table XVIII: RESULTS WITH THE IMPROVED ALLOCATION USING 
EQUAL COMMUNICATION COSTS 


Routing Multi- Best 
strategy path Path 


Execution 145.47 A205 eavieeo Out wl'4 2°. 23 
time(ms) 





Table XIX: UTILIZATION FOR THE IMPROVED ALLOCATION WITH 
EQUAL COMMUNICATION COSTS 


ee eee = 
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With this allocation, we get 0) — Semseana Riwin tien 
= 130ms. The communications overhead can be obtained by using 
the data of Table XVIII resulting 0, = 142523 — 9130) sie 
ms. The communication efficiency, as calculated by Equation 
(14), is E, = 91.4 %. The resulting processor utilizerieaa 
each node processor is shown in Table XIX. 
c. ADDING DIFFERENT COMMUNICATION COSTS TO THE 
IMPROVED ALLOCATION 
In this part, we simulate the allocation presented 
in Figure 18 but using the different communication costs shown 
in Figure 16. These costs are simulated by sending task 
synchronization messages more than once. For instance, Hija. 
16 specifies C,,= 10, therefore 10 messages are Sent frommeaes 
ay to task T,. Table XX shows the results obtained withwimma. 


Simulation. 


Table XX: RESULTS WITH DIFFERENT COMMUNICATION COSTS IN THE 
FLOW OF FIGURE 16 


Routing 
Sitpalegy 


EXecuticn 
time(ms) 





The communications overhead is obtained by using 
the data on table XX resulting O, = 208.97 — 130.0 = 75 eae 
The communications efficiency, as calculated by Equation (13), 


is E, = 62.21 %. The resulted processor utilizabien=eae cae 
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Table XXI: UTILIZATION WITH DIFFERENT COMMUNICATION COSTS 


NODE PLUTO SATURN VENUS 
Up(%) | 59.82 40.66 57.42 38.28 


node processor is shown on table XxXI. 










The constructive assignment and the iterative 
improvement must met Lec communication costs and 
interprocessor distances.We evaluate next the constructive 
assignment considering different communication costs and its 
iterative improvement. 

Ge IMPROVING THE ALLOCATION WITH DIFFERENT 

COMMUNICATION COSTS 

Figure 19 shows the allocation generated by using 
the constructive assignment heuristic considering the task 
flow with the different communication costs shown in Figure 
Ie 

In addition, Figure 20 presents the improved 
allocation obtained by using the pair-wise task interchange 
approach considering different communication costs and Table 
XXII shows its simulation results. 


VVENeE nse cdl location we get 0, — 20 ms and R_,.+0 


min ~d 
= 145 ms. The communications overhead can be obtained by using 
B@emeadicdwim Table XXII resulting in O. = 202.51 - 145 = 57.51 


ms. The communications efficiency, as calculated by Equation 
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Figure 19: Constructive assignment with differene 
communication costs 


Table XXII: RESULTS FOR THE IMPROVED ALLOCATION WITH 
DIFFERENT COMMUNICATION COSTS 


Routing Counter Multi- 
strategy clock- path 
wise 


ring 


Execution 
time(ms ) 





(13), is E, = 71.6%. The resulting processor utilizadeyomes 
each node processor is shown in Table XXIII. 
We can notice that the overhead due dependencies has 


increased from 5ms for the allocation of Figure 18 to 20ms for 
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Figure 20: Improved leeds Lom with different 
communication costs 


Table XXIII: UTILIZATION FOR THE IMPROVED ALLOCATION WITH 
DIFFERENT COMMUNICATION COSTS 


NODE pLuto | __saTuRN | _vENuS 


Up($) 61.73 44.44 54.32 41.97 





the allocation of Figure 20. However, the overall response 
time has been improved with the new allocation because the 
communication overhead has been reduced from 78.97ms to 


57.5lms. 
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Iv. CONCLUSIONS AND FUTURE WORK 


A. CONCLUSIONS 

From the communication layer description in Chapter II we 
concludes chat. 

- The communication layer package(COMLAYER) can be easily 
reused when encapsulated in a generic package. All other 
packages and procedures of the communication system will 
require the modifications described in section II.E when 
either the simulated flow/task allocation or the network 
topology changes. 

- Dit Povanteeneroacna: for routing messages can be used 
with the employed network topology. The Multipath and the Best 
Path routing strategies have improved the communication 
performance in relation to the Ring routing strategy employed 
in the first implementation[{RICHMOND 91]. In addition, these 
new approaches can also be used with higher order network 
topologies such as hypercubes or meshes. 

- The communication layer has become more robust with 
respect to deadlocks as demonstrated by the successful 
simulation of one application flow with 25 tasks in sub- 
sevrion, Lil El. 

- The communication layer limitation of having to usemes, 


one pre-defined type for all message formats precludes its use 
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with more general application task flows. Despite this 
shortcoming, the communication layer and the language ADA are 
very useful to experiment task flow simulations on transputer 
networks. 

Considering the task allocation described in chapter 
III andthe goals of minimizing the application flow response 
time and the number of processors on the network, we conclude 
feel te: 

- A constructive assignment heuristic can be employed to 
generate an initial near to optimal static task allocation 
taking into consideration task execution times~ and 
communication costs. 

—elncwinttpieal Stask allocation can be improved bys an 
iterative pair-wise interchange of tasks taking into 


consideration the interprocess communication distances. 


B. FUTURE WORK 
1. ADA ON TRANSPUTER NETWORKS 

The use of ADA on transputers network is not 
straightforward in the version of the ALSYS-ADA compiler 
available in the PARCDS-Laboratory. The main problem is that 
we need to write two OCCAM harnesses for every transputer main 
program. The process of writing OCCAM harnesses for every 
transputer node to increase the number of transputers on the 


network is very slow and error prone. Therefore, there is a 
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need for tools to generate these OCCAM harnesses automatically 
to make them totally transparent to the ADA user. 

Another problem related to the ALSYS-ADA compiler. 
that it is very slow. One program for task flow simulation 
takes about 40 minutes to be compiled. 

In addition, there are no appropriate debugging team. 
to support this ADA distributed development system. The 
programs are debugged by sending messages to the host 
transputer that is the only one that has access to the I1/0 
offered by the host PC. Furthermore, when we have a deadlock 
Situation these messages might not be delivered to the host PC 
and we get ina difficult situation to find out whet caveee 
the deadlock. 

ALSYS-~ADA is now offering a new product called ADA-MAP 
that promises solving these problems. A further evaluation is 
needed to check if this new product really solves these 
problems to justify additional investments on this ADA 
conpiler. 

2. TASK FLOW SIMULATOR 

A task flow simulator would be a useful tool to 
Support the study of task allocation on transputer networks. 
With the current approach, it is a very slow process to change 
the task allocation on the transputer network because, for 
every change, we need to rewrite parts of the programs 


COMMON.ADA, MARS.ADA, PLUTO.ADA, SATURN.ADA and VENUS.ADA. 
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A task flow simulator can be implemented by improving 
eve program STATICAL.ADA, Besides generating the task 
allocation this program would also produce the programs 
COMMON.ADA, MARS.ADA, PLUTO.ADA, SATURN.ADA and VENUS.ADA. 

For the sake of simplicity, the task flow simulator 
would run on the transputer network employed in this thesis. 
This problem is still fairly complicated because it involves 
text processing to generate the programs COMMON.ADA, MARS.ADA, 
PLUTO.ADA, SATURN.ADA and VENUS.ADA automatically from the 
task allocation computed in STATICAL.ADA. 

3. THE INMOS T9000 TRANSPUTER 

The INMOS T9000 transputer is the most recent release 
of the new generation of transputers. It runs at 50 Mhz, with 
16-Kb cache, up to 4-gigabyte of local memory, 32 bit ALU, a 
64 bit CPU, 4 bi-directional serial-communications links at 
100 Mbps each, a virtual-channel processor, a programmable 
memory interface, two on-chip timers, four pairs of event 
channels for synchronizing internal processes with external 
events, and two control links that allow control signals to be 
sent between T9000s independently of the data links. 

The new T9000 INMOS transputer has a packet-switched 
virtual communications system that takes the responsibility of 
routing messages from the programmer’s code to significantly 


faster hardware reducing the communication overhead. 
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4. EXTENDING THE TASK ALLOCATION SCHEME 

This thesis is a first step towards more elaborate 
schemes of task allocation on transputer networks. The 
following sequence of studies is suggested in order to 
gradually improve the current task allocation approach Poveae- 
the strict requirements of the next generation of real-time 
parallel canpugers. 

-Static allocation considering task placement 
constraints. 

-Static allocation considering deadlines for the tasks 
that compose the application task flow. 

-How the current static allocation scheme can be 
complemented by a dynamic allocation approach in order to 
consider aperiodic tasks. 

-How the current static allocation scheme can be 
complemented by a dynamic allocation approach to consider 
tasks with non-deterministic execution times. 

-What is the communication support and timing analysis 
tools required to implement a dynamic allocation scheme on a 
network of transputers. Investigate if the existing 
communication layer and the language ADA are still suitable 


for such a scheme. 
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APPENDIX A: OCCAM SOURCE CODE 


A. OCCAM HARNESSES ON PROCESSOR EARTH 


1. EARTHH.OCC 


#OPTION “AGNVW" 
fONCLUDE "“hostio.inc” 


PROC earth.harness (CHAN OF SP FromAda, ToAda, 
CHAN OF ANY Debug, 
CHAN OF INT Mars2Earth, Earth2Mars, 
[JANE FreeMenory ) 


#IMPORT "“earthh2.tax" 


{1]INT dummy.ws: 

wsl IS FreeMemory: 

PNT insprogram: 

ENE out program: 

SEQ 
-- Set up vector of pointers to channels. 
imeprognam| ©) += MOSTINEG INT -- not used 
LOAD.INPUT.CHANNEL (in.program[1], ToAda) 
LOAD. INPUT.CHANNEL (in.program[2], Mars2Earth) 
LOAD.OUTPUT.CHANNEL (out.program[0], Debug) 
LOAD.OUTPUT.CHANNEL (out.program[{1], FromAda) 
LOAD.OUTPUT.CHANNEL (out.program[2], Earth2Mars) 
-- Invoke the Ada program. 
-- Assumes the entry point name has been changed to 
-- "“earth.program". 
earth.program (wsl, in.program, out.program, dummy.ws) 


2. EARTHH2.OCC 


#OPTION "AEV" 


Be@e Garth.program ([]|INT wsl, in, out, ws2) 
[1000]INT d: 
SEQ 
KR IP 


v3 


3. MERGER.OCC 


#OPTION “AGNVW" 
#INCLUDE “Rosticeumc., 


PROC debug.merger (CHAN OF SP FromFiler, ToFiler, 
[ ]CHAN OF ANY Debug, 
CHAN OF BOOL Stop) 


#USE “hostio.Jibe 
-- A debug channel merger and blocker. 


VAL max.debug IS 20: 
VAL number.of.debug IS SIZE Debug: 


INT line.index: 

[256]BYTE line.buffer: 

BYTE value, r: 

BOOL running, reset, s: 
[max.debug]BOOL mask: 

VAL BYTE line.feed IS 10 (BYTE): 


SEQ 

SEQ i = 0 FOR number.of.debug 
mask[i] := TRUE 

running := TRUE 

reset := FALSE 

line.index := 0 

WHILE running 
PRI ALT 


ALT i = 0 FOR number.of.debug 
mask{[i] & Debug[i] ? value 
SEQ 
By 
value = line.feed 
SEO 
-- Send the complete line. 
sO.puts (Frompiler, Topwlem 
spid.stdout, 
{[line.buffer FROM 0 FOR line.index], 


r) 
line.index := 0 
mask [i] := FALSE 
reset := TRUE 
TRUE 

SEQ 
--~ Add character to line. 
line.buffer{line.index] := value 
line.index := line.index + 1 


reset & SKIP 
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SEQ 


Seis 2S dubs 
Se@ 1.) —)0 POR mumber.of .debug 
mask[{i] := TRUE 
SEOp 275 
running := FALSE 


4. MAINH.OCC 


#OPTION "“AGNVW" 
HONGEUDE “hostio.inc” 


PROC main.harness (CHAN OF SP FromFiler, ToFiler, 
CHAN OF INT Mars2Earth, Earth2Mars, 
[JIN FreeMemery ) 


juste ‘hostio. lib” 


#USE “earthh.t8s" 
#USE “merger.t8s" 


[1]CHAN OF ANY Debug: 
[2]CHAN OF SP FromAda, ToAda: 
CHAN OF BOOL StopDebug, StopMultiplexor: 


SEQ 
PAR 
-- A multiplexor to combine the debug and normal 
== lence, 
so.multiplexor (FromFiler, ToFiler, FromAda, ToAda, 
StopMultiplexor) 


-- A debug channel merger. 
debug.merger (ToAda[0], FromAda[0], Debug, StopDebug) 


-- A process to invoke the earth program. 
ws is FreeMemory: 
SEQ 
earth.harness (FromAda[1], ToAda[1l], Debug[0], 
Mars2Earth, Earth2Mars, ws) 
StopDebug ! FALSE 
StopMultiplexor ! FALSE 


so.exit (FromFiler, ToFiler, sps.success) 


tes) 


5. MAIN.PGM 


#INCLUDE “hostio.ine” 


#INC 


#USE 
#USE 
#USE 
#USE 
#USE 


CHAN 
Mars 
Satu 
CHAN 


PLAC 


BUDE “linkacddraine. 


‘Matai nees. 
"marsh.c8s" 
"“venush.c8s" 
"saturnh.c8s" 
“DlULOn. ces. 


OF INT Mars2Earth, Earth2Mars, Mars2Pluto, Pluto2Mamey 
2Venus,Venus2Mars, Pluto2Saturn, Saturn2Pluto, 
rn2Venus,Venus2Saturn: 

OF SP FromFiter, Toriler: 


ED PAR 


PROCESSOR 0 T8 


PLACE FromPitver AT JinkG, in: 
PLACE ToFiler AY linkOvouc: 
PLACE Mars2Earth AT link2.in: 
PLACE Earth2Mars AT link2.out: 


(325000) INT isl: 
main.harness (FromFiler, ToFiler, Mars2Earth, 


Earth2Mars, wsl1) 


PROCESSOR 1 7S 


PLACE Earth2Mars AT 1linkO.in: 
PLACE Mars2Earth AT linkO.out: 
PLACE Venus2Mars AT link2.in: 
PLACE Mars2Venus AT link2.out: 
PLACE Pluto2Mars AT link3.in: 
PLACE Mars2Pluto AT link3.out: 


[280000] INT ws2: 
mars.harness (Mars2Earth, Earth2Mars, Venus2Mars, 
Mars2Venus, Mars2Pluto, Pluto2Mars, ws2) 


PROCESSOR 2 18 


PLACE Saturn2Venus AT link2.in: 
PLACE Venus2Saturn AT link2.out: 
PLACE Mars2Venus AT lank3. an: 
PLACE Venus2Mars AT Vink3 our. 
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[280000] INT ws2: 
venus.harness (Mars2Venus, Venus2Mars, Venus2Saturn, 
Saturn2Venus, ws2) 


PROCESSOR 3 T8 


PRACHePIure7SGaturn  Amelink2 .in: 
PREACH SaturnePlute Al Meak2.out: 
PLACE Venus2Saturn AT link3.in: 
PLACE Saturn2Venus AT link3.out: 


{280000} INT ws2: 
saturn.harness (Saturn2Venus, Venus2Saturn, 
Saturn2Pilnucoe, PlutozSaturn, ws2) 


PROCESSOR 4 T8 


PLACE Mars2Pluto TUNE) aliet) 8 Bera 
PLACE Pluto2Mars Pe Pe Outs: 
PLACE Saturn2Pluto AT link3.in: 
PLACE Pluto2Saturn AT link3.out: 


{280000} INT ws2: 
pluto.harness (Mars2Pluto, Pluto2Mars, Saturn2Pluto, 
Pluto2Saturn, ws2) 


B. OCCAM HARNESSES ON PROCESSOR MARS 


1. MARSH.OCC 


#OPTION "“AGNVW" 
PENCLUDE “hostio.inc" 


PROC mars.harness (CHAN OF INT Mars2Earth, Earth2Mars, 
Venus2Mars, Mars2Venus, 

Mars2Pluto, Pluto2Mars, 

[ }INT FreeMemory) 


#IMPORT "“marsh2.tax" 


[1]INT dummy.ws: 

wsl IS FreeMemory: 
fhe) INT in.program: 
boeN? out.program: 


SEQ 
-~ Set up vector of pointers to channels. 
in.program[0] := MOSTNEG INT -- not used 
in.program{1] := MOSTNEG INT -- Standard i/o not used 


Uy 


LOAD. INPUT.CHANNEL (in.program[2], Earth2Mars) 

in.program[{[3] := MOSTNEG INT -- resemved for furuee 
-- use 

LOAD. INPUT.CHANNEL (in.program[4], Venus2Mars) 

LOAD. INPUT.CHANNEL (in.program[5], Pluto2Mars) 


out.program([0] := MOSTNEG INT -- standard i/o not used 

out.program[1] := MOSTNEG INT -- standard i/o not used 

LOAD.OUTPUT.CHANNEL (out.program[2], Mars2Earth) 

out.program(3] := MOSTNEG INT -~- reserved for future 
= Use 


LOAD.OUTPUT.CHANNEL( out.program[4], Mars2Venus) 
LOAD.OUTPUT.CHANNEL (out.program[5], Mars2Pluto) 

-- Invoke the Ada program. 

-- Assumes the entry point name has been changed to 
== “Mars.program . 

mars.program (wsl, in.program, out.program, dummy.ws) 


2. MARSH2.0CC 


#OPTION "AEV" 


PROC mars.program ([{]INT wsl, in, out, ws2) 
(L000) INT a: 
SEO 
SKIP 


C. OCCAM HARNESSES ON PROCESSOR PLUTO 


1. PLUTOH.OCC 


#OPTION "AGNVW" 
fINCLUDE="KhoOstie.1nc- 


PROC pluto.harness (CHAN OF INT Mars2Pluto, Pluto2Mars, 
Saturn2Pluto,Pilurezsacurn, 
[| INT FreeMenor,) 


*#IMPORT “plutoh2. tax” 


[1]INT dummy.ws: 

wsil [15 FreeMemory: 

(6 IND sinsprogram: 

([6JINT Cut. program: 

SEQ 
-- Set up vector of pointers to channels. 
in.program[0] := MOSTNEG INT -- not used 
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MOSTNEG INT -- standard i/o not used 

MOSTNEG INT -- reserved for future 
-- use 

LOAD. INPUT.CHANNEL (in.program[{3], Mars2Pluto) 

LOAD. INPUT.CHANNEL (in.program{4], Saturn2Pluto) 


in. program{ 1} 
in.program[ 2] 


i eneognan(| 29. — MOSTNEG INT See SOL VecmLOn LuLure 
-- use 
out.program[0] := MOSTNEG INT -- standard i/o not used 


out.program[1] := MOSTNEG INT -- standard i/o not used 
out.program{2] := MOSTNEG INT -- reserved for future 
-- use 


LOAD.OUTPUT.CHANNEL (out.program[3], Pluto2Mars) 

BOAUROUTPUT. CHANNEL (OUuT.~pregram(4)], Pluto2zSaturn) 

out.program[5] := MOSTNEG INT -- reserved for future 
-- use 

-- Invoke the Ada program. 

-- Assumes the entry point name has been changed to 

-- "pluto.program". 

pluto.program (wsl, in.program, out.program, dummy.ws) 


2. PLUTOH2.0CC 


#OPTION "AEV" 


EROC pluto.program ({]INT wsl, in, out, ws2) 
PEOOO INT a: 
SEQ 
SKIP 


D. OCCAM HARNESSES ON PROCESSOR SATURN 
1. SATURNH.OCC 
#OPTION "AGNVW" 
PONCLUDE “hostio.inc" 
PROC saturn.harness (CHAN OF INT Saturn2Venus, Venus2Saturn, 
SaturnieP libro, PiuroZsaturn, 
Pot FP reeliemory ) 
#IMPORT "“Saturnh2.tax" 
[1]INT dummy.ws: 
wot ls FreeMemory ; 


[6]INT in.program: 
[6JINT out.program: 


2) 


SEQ 
-- Set up vector of pointers to channels. 
in.program(/0] :—= MOSTNEG SIN”? -- not used 


in.program[1] := MOSTNEG INT ~- standard i/o not used 


LOAD. INPUT.CHANNEL (in.program| 2], 9°? ivee2>sceuan) 
LOAD. INPUT.CHANNEL (in.program| 3], "VenusZsacua 


in.program[4] := MOSTNEG INT -- reserved for fucume 
-- use 

in.program| S|] ":—= MOSTNEG ING ~- reserved for future 
-- use 

out.program[0] := MOSTNEG INT -~- standard i/o not used 

out.program[1] := MOSTNEG INT -- standard i/o not used 


LOAD.OUTPUT.CHANNEL (out.program[ 2], Saturnz? lee 
LOAD.OUTPUT.CHANNEL (oOut.program| 3), Sadturnzvena» 


out.program[(4] := MOSTNEG INT -- reserved for future use 
out.program[5] := MOSTNEG INT -- reserved for future use 


-- Invoke the Ada program. 
-- Assumes the entry point name has been changed to 
=> Satur erogran = 


saturn.program (wsl, in.program, out.program, dummyswey 


2. SATURNH2.OCC 


#OPTION “AEV" 
PROC saturn.program ([]INT wsl, in, out, ws2) 
P1000 | CNTs. 
SEQ 
SKIP 
E. OCCAM HARNESSES ON PROCESSOR VENUS 
1. VENUSH.OCC 
#OPTION "AGNVW" 
#INCLUDE “hoseiogine. 
PROC venus.harness (CHAN OF INT Mars2Venus, Venus2Mars, 
Venus2Saturn, Saturn2Venus, 
[jINT FreeMenory) 
#IMPORT “venush2.tax" 
[1]INT dummy.ws: 


wsl ~bs FreemMenory: 
[Go] IND ins program. 
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Lo ieoutir progr am: 


SEQ 
-- Set up vector of pointers to channels. 
in.program[0] := MOSTNEG INT -- not used 
in.program{1] := MOSTNEG INT -- standard i/o not used 
LOAD. INPUT.CHANNEL (in.program[{2], Mars2Venus) 
in.program{3] := MOSTNEG INT -- not used 
in.program{4] := MOSTNEG INT -- reserved for future 
-- use 
LOAD. INPUT.CHANNEL (in.program[5], Saturn2Venus) 
out.program{0] := MOSTNEG INT -- standard i/o not used 
Guc. program; 1) :— MOSTNEG INT -- standard i/o not used 
LOAD.OUTPUT.CHANNEL (out.program[2], Venus2Mars) 
out.program{3] := MOSTNEG INT -- reserved for future use 
out.program{4] := MOSTNEG INT -- resereved for future 
-- use 


LOAD.OUTPUT.CHANNEL (out.program[5], Venus2Saturn) 

-- Invoke the Ada program. 

-- Assumes the entry point name has been changed to 

=-—- ‘véenus.procram’. 

venus.program (wsl, in.program, out.program, dummy.ws) 


2. VENUSH2.OCC 


#OPTION "AEV" 


PROC, venus.program ([ ]INT wsl, in, out, ws2) 
SLOOO)INT d: 
SEQ 
SOs 


en 


APPENDIX B: COMMUNICATION LAYER/AUV FLOW ADA SOURCE CODE 


A. COMMUNICATION LAYER ADA PROGRAMS 


1. COMMON.ADA 


with CHANNELS; 
with CALENDAR; 


package COMMON is 


-- Declarations of the statistics of the network and the 
-- common data types that are used in the communication 


-- scheme. 

NUM_PROGS : constant INTEGER. — 3.5, 
NUM PATHS < Constant INTEGER := 13; 
NUM ENTRYS ~; constant INTEGER =— 19) 
type INT.16 is range —2**15 2 2 oe 


type TASKS is (HOST_TASK, TASK SCREEN, TASK AUTO PILOT, 


subtype 


TASK TIMER, TASK _VEHICLE_SYS, 

TASK EXE MISSION, TASK MONITOR, 
TASK AVOIDANCE, TASK GUIDANCE, 
TASK NAVIGATION, TASK SONAR, 

EARTH MAIN, MARS MAIN, VENUS MAIN, 
SATURN MAIN, PLUTO MAIN, 

NO_ TASK, SHUTDOWN, LOOP TASK); 


EARTH_TASKS is TASKS range 


HOST_TASK..TASK_SCREEN; 


subtype 
subtype 
subtype 
subtype 


subtype 
subtype 


MARS_TASKS is TASKS range 

TASK AUTO PILOT..TASK_VEHICLE_ SYS; 

PLUTO_TASKS is TASKS range 
TASK_EXE_MISSION..TASK_MONITOR; 

SATURN_TASKS is TASKS range 

TASK AVOIDANCE. .TASK_ GUIDANCE; 

VENUS TASKS is TASKS range 

TASK NAVIGATION. .TASK_ SONAR; 

MAIN TASKS is TASKS range EARTH_MAIN..PLUTO MAIN; 
SPECIAL TASKS is TASKS range NO TASK..LOOP_TASK; 


type PROG_ARRAY is array (1..NUM_PROGS) of INTEGER; 
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type PATH_ARRAY is array (1..NUM_PATHS) of INTEGER; 
type PROGRAMS See (EARTH, OMARS, VENUS, SATURN, PLUTO); 


type ROUTING STRATEGY is (CNT_CLK_RING, CLK RING, 
MULTI PATH, BEST PATH); 


type OUT_TABLE is array(PROGRAMS range <>, NATURAL range 
<>) of BOOLEAN; 

type POINTER TABLE is access OUT_TABLE; 

type POINTER CHANNEL is access CHANNELS.CHANNEL ARRAY; 


type COUNT_OUTPUTS is array(PROGRAMS range <>) of 
NATURAL; 

hemor SOULPDRS : SCOUNT OUTPUTS (MARS.. PLUTO) := (3, others 
es 2) 


type CONFIG TABLE MARS is array(ROUTING STRATEGY) of 
OUT_TABLE(EARTH..PLUTO,0..NR_OF_OUTPUTS(MARS)-1); 
MARS CONFIG: CONFIG TABLE MARS := 


((-- counter clockwise ring 
-- OutToEarth OutToVenus OutToPluto 
(TRUE, FALSE, FALSE), -- EARTH 
(FALSE, FALSE, FALSE), -- MARS 
(FALSE, FALSE, TRUE, -- VENUS 
(PALSER FALSE, TRUE), -- SATURN 
(FALSE, FALSE, TRUE)), -- PLUTO 
(-- clockwise ring 
-- OutToEarth OutToVenus OutToPluto 
(TRUE, FALSE, FALSE), -- EARTH 
(FALSE, FALSE, FALSE), -- MARS 
(FALSE, TRUE, FALSE), -- VENUS 
(FALSE, TRUE, PASH), —= SATURN 
(FALSE, TRUE, FALSE)), -- PLUTO 


(-- Multipath 
-- OutToEarth OutToVenus OutToPluto 


(TRUE, FALSE, FALSE), -- EARTH 
(FALSE, FALSE, FALSE), -- MARS 
(FALSE, TRUE, FALSE), -- VENUS 
(FALSE, TRUE, TRUE), -- SATURN 
(FALSE, FALSE, TRUE)), -- PLUTO 


(-- Bestpath 
-- OutToEarth OutToVenus OutToPluto 


(TRUE, FALSE, FALSE), -- EARTH 
(FALSE, FALSE, FALSE), -- MARS 
(FALSE, TRUE FALSE), -- VENUS 


BS) 


(FUSES 
(FALSE, 


TRUE, 
FALSE, 


FALSE 
TRUE) 


; SATURN 
\; -- PLUES 


) 
) 


type CONFIG TABLE PLUTO is array(ROUTING STRATEGY) of 
OUT TABLE(EARTH..PLUTO,0..NR_OF OUTPUTS(PLUTO)-1); 


PLUTO CONFIG: CONFIG TABLE S2EUTS..— 

({(== counter clockwise wring 

--OutToMars OutToSaturn 
(FALSE, TRUE -- EARTH 
(FALSE, TRUE G -- MARS 
(FALSE, TRUE -- VENUS 
(FALSE, CRUE Ne -- SATURN 
(FALSE, FALSE)), -- PLUTO 

(-- clockwise ring 

--OutToMars OutToSaturn 
(TRUE, FALSE), -- EARTH 
(TRUE, FALSE), -- MARS 
(TROE; FALSE), -- VENUS 
(TRUE, FALSE), -- SATURN 
(FALSE, FALSE) -- e250 16 

(-- Multipath 

--OutToMars OutToSaturn 
(TRUE, FALSE. -- EARTH 
(TRUE, FALSE), -- MARS 
(TRUE, TRUE), -- VENUS 
(FALSE, TRUE), -- SATURN 
(FALSE, FALSE)),  -- PLUTO 

(-- Bestpath 

--OutToMars OutToSaturn 
(TRUE, FALSE] -- EARTH 
(TRUE, FALSE 3 -- MARS 
(FALSE, Bu eaUN Ry A -- VENUS 
(PAULGE, TRUE), -- SATURN 
(FALSE, FALSE))); -- PLUTO 


type CONFIG TABLE SATURN is array(ROUTING STRATEGY) of 
OUT TABLE( EARTH. .PLUTO,0..NR_ OF OUTPUTS ( SATURN ae 


SATURN _CONFIG: CONFIG TABLE 


Ct 


OutToVenus 
(TRUE; 
(TRUE, 
(LEU; 
(FALSE, 
(TRUE, 


_ SATURN 


-- counter clockwise ring 


OutToPluto 

FALSH),) 62) EARTH 
FALSE), -- MARS 
FALSE), -- VENUS 
FALSE), -- SATURN 
FALSE ))jeeee Lule 
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type CONFIG TABLE VENUS 


( -- clockwise ring 


- OutToVenus OutToPluto 
(FALSE, TRUE ); -- EARTH 
(FALSE, TRUE), -- MARS 
(FALSE, wi), -- VENUS 
(FALSE, FALSE), -- SATURN 
(FALSE, TRUE)), -- PLUTO 
( -- Multipath 

- OutToVenus OutToPluto 
CIRUE, TRUE), -- EARTH 
(TRUE, TRUE) 8 -— MARS 
CERUE, FALSE), -- VENUS 
(FALSE, FALSE), -- SATURN 
(FALSE, TISIOVS pp = — SALI BS 
( -- Bestpath 

- OutToVenus OutToPluto 
(FALSE, TRUE), -- EARTH 
(FALSE, TRUE), -- MARS 
(TRUE, FALSE), -- VENUS 
(FALSE, FALSE), -- SATURN 
(FALSE, PRUE) ) ); == PLUTO 


is array(ROUTING STRATEGY) of 


OUT_TABLE(EARTH. .PLUTO,0..NR_OF_OUTPUTS(VENUS)-1); 


VENUS_CONFIG: 


CONFIG TABLE _VENUS 


((-- counter clockwise ring 

-- OutToMars, OutToSaturn 
CiRUE, FALSE), -- EARTH 
CIRUE; FALSE), -- MARS 
(FALSE, FALSE), -- VENUS 
CIRUE, FALSE), -- SATURN 
CTRUE ; Babs) == PLUTO 
(-- clockwise ring 

-- OutToMars, OutToSaturn 
(FALSE, TRUE), -- EARTH 
CHAISE: TRUE), -- MARS 
(FALSE, FALSE), =— VENUS 
(FALSE, TRUE), -- SATURN 
(FALSE, TRGE))i == Eau 
(-- Multipath 

-- OutToMars, OutToSaturn 
CERUE: FALSE), -- EARTH 
CER UE FALSE), -- MARS 
(FALSE, FALSE), -- VENUS 
(FALSE, TRUE),  -- SATURN 


S15) 


(TRUE, TRUE) ), == Prue 


(-- Bestpath 
-- OutToMars, OutToSaturn 


(TRUE, FALSE), ==) BARGE 
(TRUE, FALSE) == MARS 
(FALSE, FALSE) ove NS 
(FALSE, TRUE), -- SATURN 
(TRUE, FALSE) ))> === EEuw@ 


type ENTRYS is (OUTPUT, UPDATE SONAR, VS ORDERS, 
SYS_STATUS,AP_ORDERS,UPDATE_NAV, 
UPDATE ORDERS, AVOID REC, SONAR_OBSTICLE, 
OBJECT ALERT, EXE_UPDATE, OB AVOID, 
MONITOR_UPDATE, TO MONITOR, PILOT _UPDATE, 
ACKNOWLEGE, NO ENT, RETURNING, 


Te Ss) EME 
type MESSAGE FORM is 
record 
ORIGIN ; TASKS := NO TASK; 
DE sith : TASKS = NO TASK; 
ENT CALL : ENTRYS := NO@ENT: 
TIMES STAMP ; DURATION <="020; 
COpey1 INT oe 0, 
CODE_2 t ONT oe: 07 
MESSAGE CODE <= INTEIG02—) 0, 
PROG >; PROG ARRAY := (others =)0); 
PATH >: PATH_ARRAY := (others =)0); 


end record; 


type MASK TYPE is array(MARS. .PLUTO) Gf BOOLEAN, 


type CONFIG MESSAGE is 


record 
MASK : MASK TYPE := (others => FALSE); 
ROUT_INFO : ROUTING STRATEGY; 


end record; 


type PERIOD MESSAGE is 
record 
MASK : MASK TYPE := (others => FALSE); 
PERIOD INFO ; DURATION; 
end record; 
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SHUTDOWN_MESSAGE : MESSAGE FORM := (SHUTDOWN, SHUTDOWN, 
Homie 0, O07 807) 0, (Others => 0), (ethers => 9)); 


HOST : constant PROGRAMS := EARTH; 
READ_INT ; cOnsSvane DURATION <= (5.0; 
-- Instantiations of the generic channel i/o package. 


package MESSAGE _IO is new CHANNELS.CHANNEL_ IO 
(MESSAGE _ FORM); 

package CONFIG IO is new CHANNELS.CHANNEL_ IO 
(CONFIG MESSAGE); 

package PERIOD_IO is new CHANNELS.CHANNEL_ IO 
(PERIOD MESSAGE); 


function IF_ITS_HERE (FROM PROGRAM : in PROGRAMS; TO_TASK 
in TASKS) return BOOLEAN; 


function WHERE IS (IN_TASK: in TASKS) return PROGRAMS; 
end COMMON; 
package body COMMON is 


function IF_ITS HERE (FROM PROGRAM : in PROGRAMS; TO TASK 
in TASKS) return BOOLEAN is 


begin 
case FROM PROGRAM is 
when EARTH => 
case TO TASK is 
when EARTH _TASKS’FIRST..EARTH_TASKS’LAST => 
return TRUE; 
when others => 
BeLupnietALSE. 
end case; 
when MARS => 
case TO TASK is 
when MARS_TASKS’FIRST..MARS_TASKS’LAST => 
return TRUE; 
when others => 
return FALSE; 
end case; 
when PLUTO => 
case TO TASK is 
when PLUTO TASKS’FIRST..PLUTO TASKS’LAST | 
LOOP TASK => 
EPeburn TRUE: 
when others => 


87 


Cepia sok, 
end case; 
when SATURN => 
case TO TASK is 
when SATURN_TASKS'FIRST..SATURN_TASKS'LAST => 
recur TRUE: 
when others => 
return FALSE; 
end case; 
when VENUS => 
Case TO TASK lis 
when VENUS_TASKS’ FIRST. .VENUS TASKS EAST —> 
return 1RUn; 
when others => 
return FALSE; 
end case; 
when others => 
return FALSE; 
end case; 


end IF_ITS HERE; 
function WHERE_IS(IN TASK: in TASKS) return PROGRAMS is 


begin 
Case INJTASK 16 
when EARTH TASKS'FIRST. .EARTH TASKS’ LAST => 
return EARTH 
when MARS_TASKS’FIRST..MARS_ TASKS’LAST => 
return MARS; 
when PLUTO TASKS'FIRST..PLUTO_TASKS’LAST ; LOOP_TASK 
=> 
return PRUTO-; 
when SATURN TASKS'FIRST. .SATURN_TASKS’* LAST => 
return SATURN; 
when VENUS_TASKS’FIRST..VENUS_ TASKS’LAST => 
return VENUS; 
when others => 
return MARS; 
end case; 
end WHERE_IS; 


end COMMON; 


2. COMLAYER.ADA 


with COMMON; 
use COMMON; 
with CALENDAR; 
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use CALENDAR; 
with CHANNELS; 
with RANDOM; 


generic 


--Function to be instantiated on each node program. 
--This function issues entry calls that send messages to 
--local tasks. 
with procedure SEND_IT (MESSAGE: in MESSAGE FORM; 

MESS: out BOOLEAN); 


package COMLAYER is 


--Local mailman implemented by a circular buffer.Puts the 
--local arriving messages in a circular buffer and 
--distribute them to the local tasks. 
task QUE is 
-- Called by the task INOUT to pass a local message. 
entry TO QUE (QUE_MESSAGE: in MESSAGE_FORM); 
end; 


--Traffic handler: Sends the local messages to task QUE 
--and sends the external messages to the remote nodes 
--through appropriate output channels. 

task INOUT is 


entry INIT1 CS Ibe : in PROGRAMS); 
entry INIT2 (SEND ARRAY : 
in CHANNELS.CHANNEL ARRAY); 
ewery ONDTS (SEND TABLES. sin, OUT TABLE); 
entry INCOMING (INOUT_MESSAGE : in MESSAGE FORM); 
entry SEND (INOUT_MESSAGE : in MESSAGE_FORM); 
end; 


end COMLAYER; 


package body COMLAYER is 


--Local mailman implemented by a circular buffer.Puts the 
--local arriving messages in a circular buffer and 

--distribute them to the local tasks. 
task body QUE is 
ZO 


MAX STORAGE ; constant INTEGER := 
--Circular buffer size 
SENT MESSAGE : BOOLEAN := FALSE; 


--Indicates if the rendevouz for local message delivery 
--was accomplished succssefully. 

ALL_ FULL : BOOLEAN >= FALSE; 
--Indicates that the circular buffer is full. That 
--is,there is no more room for an incoming message. 
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PEND MESS >: BOOLEAN -= FASE 
--Indicates that there is a pending message waiting 
--for a position in the circular buffer. 

FULL > constant BOOLEAN := TRUE; 
--Indicates that the current position of the circular 
-~-buffer contains valid message which is still 

--to be delivered. 

EME >: constant BOOLEAN := FALSE; 
--Indicates that the current position of the circular 
--buffer has a non valid message. That is, this 
--position is empty or this message has already been 
--delivered and can be discarded. 

NUMBER : INTEGER := 0; -- Index that 
-“=points £oO a Circular butter posite: 

MESSAGES _IN_MAIL: INTEGER := 0; -- Control iene 
--number of messages in the circular buffer. 

SLOT: array(0 .. (MAX STORAGE-1)) of BOOLEAN := 
(others => FALSE); 

--SLOT indicates if the pointed circular buffer 
--position contains a valid message or not. 

STORAGE > array(0O .. (MAX _STORAGE-1)) of 
MESSAGE FORM; 

--STORAGE is the array that implements the circular 
--buffer. 

TEMP_MESSAGE : MESSAGE FORM; -- temporary variable to 
--hold the incoming message. 


begin 
MAIN: loop 
select 
--Accept calls from the task INOUT with arriving 
--local messages 
accept TO QUE (QUE MESSAGE : in MESSAGE FORM) do 


TEMP_MESSAGE := QUE MESSAGE; 
end TO _OUB;; 
-- Puts the message into the circular buffer 
STORAGE (NUMBER) := TEMP_MESSAGE; 
MESSAGES_IN MAIL := MESSAGES _IN_ MAIL + 1; 
SLOT (NUMBER) := FULL; 


-~Priority is given to any messages waiting to be 
--mailed, so another accept statement is needed 
--before attempting to deliver a message. 


SEND: loop 
if ALL _FULL = FALSE then -- the ciréulanwsiiren 
--has room for a new incoming message. 
select 


--Accept calls from the task INOUT with 
=-arriving local messages. 
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accept TO QUE (QUE MESSAGE : in MESSAGE FORM) 


do TEMP_MESSAGE := QUE_MESSAGE; 
end TO QUE; 
if MESSAGES _IN MAIL < MAX STORAGE then -- If 


--the circular buffer has room for a new 
--incoming message searches for the next 
--free position in the circular buffer 
--and stores the message in this position. 
STORE: loop 
if SLOT(NUMBER) = EMPTY then 
--Free position was found. 
--Puts the message into the circular 
--buffer. 
STORAGE(NUMBER) := TEMP MESSAGE; 
MESSAGES IN MAIL := MESSAGES IN MAIL+1; 
SHOT CHUMBER ys — PF ULii, 
exit; 
end if; 
--Add 1 to NUMBER so that next mail slot 
--can be checked. 
NUMBER := (NUMBER + 1) MOD MAX STORAGE; 
Cucmlocp SlORE; 


--Searches for the next used position in the 
Senne bar Dubie , 
if MESSAGES IN MAIL /= 0 then 


NUMBER := (NUMBER + 1) MOD MAX STORAGE; 
while SLOT(NUMBER) /= FULL loop 
NUMBER := (NUMBER + 1) MOD MAX_STORAGE; 
Endep loop, 
eng rn: 
else 


--the circular buffer has no room for a 
--new incoming message. 


Aiiee Unb: = TRUE; 
PEND MESS := TRUE; 
end ii; 
or 
--cannot accept a new message from task INOUT 
--so suspends the task and puts the task at 
--the end of the ready queue. 
delay 0.0; 
end select; 
ypol sskie 4 


=—Jeeehe scireulan butter position contains a valid 
--message call SEND_IT in order to issue an entry 
--call for message delivery. 


ol 


if SLOT(NUMBER) = FULL then 
SEND_IT (STORAGE (NUMBER) > SENTaMae e2Gee 
eng ire 


--if a rendevouz with the destination task has 
--ocurred then the message was successfully sent 
--to its destination. 

if SENT MESSAGE then 


SENT MESSAGE := FALSE; -- turn off the flag 
SLOT(NUMBER) := EMPTY; -- liberates circular 
-- buffer position 

MESSAGES IN MAIL := MESSAGES IN MAIL - 1; 


if PEND MESS then --it here sea) pencume 
--message store the pending message in the 
--just freed circular buffer positienr 


STORAGE (NUMBER) := TEMP MESSAGE; 

SLOT (NUMBER) := FULL; 

MESSAGES _IN_ MAIL := MESSAGES IN MAIL + 1; 

PEND MESS = FAESE, 

NUMBER := (NUMBER + 1) MOD MAX STORAGE; 
end if; 


--updates the status of the boolean variable 
--ALL FULL which indicates whether the circular 
--buffer is full or not 

if MESSAGES IN MAIL < MAX STORAGE then 


ALL FULL := FALSE; 
else 

ALL PULL := TRUE; 
end if; 


else --The message was not succssefully sent so it 
--loses its turn and has to wait for the next 
--cCircular buffer scan 
NUMBER := (NUMBER + 1) MOD MAX STORAGE; 

end a2° 


--To save processor time the loop is exited when 
--there are no pending mail deliveries. 
exit when MESSAGES _IN MAIL = 0; 
end loop SEND; 
(one 
terminate; 
end select; 
end loop MAIN; 
end QUE: 
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--Traffic handler: Sends the local messages to task QUE 
--and sends the external messages to the remote nodes 
--through appropriate output channels. 

task body INOUT is 


HERE : BOOLEAN; -- indicates if the message is 
--destinated to the local node or to an external node. 
STORAGE MESSAGE: MESSAGE FORM; --message just arrived 
--in the traffic handler 

CURRENT_NODE : PROGRAMS; --local processor ID 
OUT_CHANNEL > CHANNELS.CHANNEL REF; --it will 


--point to the output channel to be writen by the task 
--INOUT when sending a message to a external processor. 
DEST_PROGRAM : PROGRAMS; --holds the processor ID 
--of the message destination 

--The IND_INDEX array is used to hold all the possible 
--indexes that points to the output channels which can 
--be used to send messages to a specific processor. 
--These indexes can reference the output channels when 
--used with CURRENT ARRAY 

type INDEX_ARRAY is ARRAY(NATURAL range <>) of NATURAL; 
IND_INDEX: INDEX _ARRAY(0..3); --Indirect index array for 
--the output channels 

OUT_COUNT: NATURAL; --counter used as index for the 

a NOP INDEX array 

TOSS: FLOAT; -- random variable that is used when we 
--have more than one possible output channel to send a 
--message to a specific processor. 

CURRENT_ARRAY : POINTER_CHANNEL; -- It is an acess type 
--variable which type is defined in the package COMMON. 
--CURRENT_ARRAY points to the array of output channels 
--to be used by the task INOUT. 

CURRENT_TABLE : POINTER_TABLE; --It is an acess type 
--variable which type is defined in the package COMMON. 
--CURRENT_TABLE points to the rounting table to be used 
Oy eene seOuUntINngG algorithm. 


ARRIVED >; BOOLEAN := FALSE; 
Begin 

-- Accept intialization messages from the main processor 

--program 

accept INIT1 (SITE : in PROGRAMS) do 
CURRENT_NODE := SITE; loca mo LOocessor ID 

ena INIT: 

accept INIT2 (SEND ARRAY : in CHANNELS.CHANNEL ARRAY) do 
CURRENT ARRAY := new 
CHANNELS.CHANNEL ARRAY’ (SEND ARRAY); -- output 
-~-channels array 

end) LNW? > 


e) 


accept INIT3 (SEND TABLE: in OUP TABLE Mac 
CURRENT TABLE := new OUT TABLE SS rhtei7 eras 
--routing table 

end INIT3; 


loop 
select 
--Used to accept messages just arrived from 
--external nodes.Called by each main node program. 
accept INCOMING (INOUT_MESSAGE : in MESSAGE _FORM) do 
STORAGE MESSAGE := INOUT_MESSAGE; 
ARRIVED <= TRUE; 
end INCOMING; 
or 
--Used to accept messages from local tasks. 
accept SEND (INOUT_MESSAGE: in MESSAGE FORM) do 


STORAGE _ MESSAGE := INOUT_MESSAGE; 
ARRIVED := TRUE; 
end SEND; 
or 
--terminate; 
delay 0.001; 


end select; 


if ARRIVED then 
ARRIVED := FALSE; 
OUT_COUNT := 0; --initialize counter used as index 
=-for the INDUINDExwarray 
--Find the destination processor by using the 
--function WHERE_IS which 
--is declared in the package COMMON 
DEST _PROGRAM := WHERE _IS (STORAGE MESSAGE.DESTIN); 
--Verifies if the message is for the local node or 
--for an external processor 
if DEST PROGRAM = CURRENT NODE then 


HERE := TRUE; 
else 
HERE := FALSE; 
end if; 
if HERE then -- if destination is the local node it 


--passes the message to the local mailman 
QUE.TO_QUE (STORAGE MESSAGE); 
else 
--Destination is an external processor 
--Search for all output channels that can be used 
--to communicate with the destination processor 
--and store this information in the IND_INDEX 
--array 
for J in CURRENT TABLE.all’ RANCH (2 Slee 
if CURRENT_TABLE(DEST_PROGRAM, J) = TRUE then 
IND_INDEX(OUT_COUNT) := J; 
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e. RAN _INT.ADA 
separate (RANDOM) 


mineelon SANDOMPINT (N : POSIPIVE) return POSITIVE is 


BeSUDD : INTEGER range 1 =. N; 

begin 
RESULT := INTEGER (FLOAT (N) * UNIT_RANDOM + 0.5); 
mBeturi REoULT ; 

exception 


when CONSTRAINT ERROR | NUMERIC_ERROR => 
-- If machine rounds 0.5 down to 0, return 1. 
meturn i; 
end RANDOM_INT; 
B. HOST ADA PROGRAMS 
1. HOSTLAY.ADA 
with COMMON; 
use COMMON; 
generic 
--Function to be instantiated 
with procedure SEND IT (MESSAGE: in MESSAGE FORM; 
ACK: out BOOLEAN; 
MESS: out BOOLEAN); 
package HOST_LAYER is 
task EARTH_QUE is 
entry TO QUE (QUE MESSAGE: in MESSAGE FORM); 


end; 


end HOST LAYER; 


package body HOST LAYER is 


task body EARTH_QUE is 


MAX STORAGE meconoecanc INTEGER := 20; 

SENT MESSAGE : BOOLEAN = FALSE; 
SENT_ACK >: BOOLEAN = FALSE; 
ALL_FULL : BOOLEAN = FALSE; 


OF 


PEND_MESS >: BOOLEAN = FASE: 
FULL ; constant BOOLEAN <=" Tee, 
EMPTY >: constant BOOLEAN := FALSE; 
NUMBER : INTEGER = 0; 
MESSAGES IN MAIL: INTEGER = 0; 
SLOT: array (0 .. (MAX_STORAGE-1) ) af BOOLEAN := (others 
=> FALSE); 
STORAGE: array(0 .. (MAX_STORAGE-1)) of MESSAGE FORM; 
TEMP_MESSAGE >; MESSAGE FORM; 
begin 
MAIN: loop 
select 
accept TO QUE (QUE_MESSAGE : in MESSAGE _ FORM) do 
TEMP MESSAGE := QUE MESSAGE; 
end “lO QUE; 
STORAGE (NUMBER) := TEMP MESSAGE; 
MESSAGES IN MAIL := MESSAGES_IN “MAIL + 1; 
SLOT (NUMBER) := FULL; 


--Priority is given to any messages waiting to be 
--mailed, so another ACCEPT statement is needed 
--before attempting to deliver a message. 


SEND: loop 
if ALL FULL = FALSE then 
select 
accept TO QUE (QUE MESSAGE : in MESSAGE FORM) 
do 
TEMP_MESSAGE := QUE MESSAGE; 
end TO_QUE; 


if MESSAGES IN MAIL < MAX STORAGE then 
STORE: Loop 
if SLOT(NUMBER) = EMPTY then 


STORAGE(NUMBER) := TEMP MESSAGE; 
MESSAGES _IN MAIL := MESSAGES IN MAIL+1; 
SLOT ( NUMBER } 7 —s5 Ui 
exit; 

end if; 


--Add 1 to NUMBER so that next mail slot 

--can be checked. 

NUMBER := (NUMBER + 1) MOD MAX STORAGE; 
end loop STORE; 


--Add 1 to NUMBER so that last in will not 
--be forst out if there are other messages 
--in the queue 
if MESSAGES IN MAIL /= 0 then 

NUMBER := (NUMBER + 1) MOD MAX_STORAGE; 


oi 


while SLOT(NUMBER) /= FULL loop 
NUMBER := (NUMBER + 1) MOD MAX_STORAGE; 
end loop; 
end if; 


--This is a flag that says that are 
--incoming messages not yet stored in 
--the queue, and no others should be read 
=-UnNtrl it is. 


else 
AEE FUELS. = TRUE; 
PEND MESS :- TRUE; 
end if; 
or 
delay 0.0; 
end select; 
end if; 
if SLOT(NUMBER) = FULL then 
SEND_IT (STORAGE (NUMBER), SENT_ACK, 
SENT MESSAGE); 
end if; 


if SENT_MESSAGE then 
SENT_MESSAGE := FALSE; 
SLOT(NUMBER) := EMPTY; 
MESSAGES IN MAIL := MESSAGES IN MAIL - 1; 


if PEND MESS then 


STORAGE(NUMBER) := TEMP MESSAGE; 

SLOT(NUMBER) := FULL; 

MESSAGES _IN MAIL := MESSAGES IN MAIL + 1; 

PEND_MESS >= FALSE; 

NUMBER := (NUMBER + 1) MOD MAX STORAGE; 
end if 


if MESSAGES _IN_ MAIL < MAX STORAGE then 


ALL_FULL := FALSE; 
else 
Nigh, MOA, B= WWI 
end if; 
else 
NUMBER := (NUMBER + 1) MOD MAX STORAGE; 
end i > 


-- To save processor time the loop is exited when 
-- there are no pending 
-- mail deliveries. 


exit when MESSAGES IN MAIL = 0; 


end loop SEND; 
Or 


ag 


terminate; 
end select; 
end loop MAIN; 


end EARTH _QUE; 
end HOST LAYER; 


2. EARTH.ADA 


With VER PO; 
with COMMON; 

use COMMON; 

with PRINTOUT; 
use PRINTOUL; 
with HOST LAYER; 
with CHANNELS; 
with CALENDAR; 
use CALENDAR; 


procedure EARTH is 


package INTEGER_INOUT is new TEXT IO.INTEGER 10O( INTEGHRES 
use INTEGER 1NOUT; 

package TIME _IO is new TEXT_IO.FIXED_IO(DURATION); 
package FLT 10 is new TEAT 10. FLOAT 1O(hioaiay, 


CONFIG OPTION : INTEGER; 

IN MESSAGE : MESSAGE FORM; 
MAIN TALK  : MESSAGE FORM; 
FIRST MESSAGE: CONFIG MESSAGE; 
SECOND MESSAGE: PERIOD MESSAGE; 


LOCATION >: constant PROGRAMS := EARTH; 
TIME. OULE : TIME; 

GUT TIME ; TOME: 

ABORTED : BOOLEAN; 

FAILED  IN@DS 0; 

MESS COUNT 5 INETSIG 0; 

OULT IND : DURATION == "35.0; 

PERIOD : DURATION; 


MESSAGE ERROR: exeeption:, 


InFromMars: CHANNELS.CHANNEL REF := 
CHANNELS.IN_PARAMETERS (2); 
OutToMars: CHANNELS.CHANNEL REF := 
CHANNELS .OUT_PARAMETERS (2); 


task SCREEN is 


entry OUTPUT (SCREEN MESSAGE. in MESSAGE FORM); 
end; 


Oe) 


procedure SEND_IT_FROM_ EARTH (MESSAGE: in MESSAGE FORM; 


ACK : out BOOLEAN; 
MESS : Out BOOLEAN) is 
MESSAGE SENT: BOOLEAN := FALSE; 
ACK_SENT : BOOLEAN := FALSE; 
begin 
select 
SORBEN  OULPUT (MESSAGE ) >; 
MESSAGE SENT := TRUE; 
or 
delay 0.01; 
end select; 
ACK := ACK SENT; 
MESS := MESSAGE SENT; 
return; 


end SEND IT FROM EARTH; 

package EARTH LAYER is new HOST LAYER(SEND IT FROM EARTH); 
mse EARTH LAYER; 

task body SCREEN is 


OUT2SCREEN: MESSAGE FORM; 


LOCALS meoendy (TASKS) Of INT J16 2—= (others => 0); 
COUNT : INTEGER := 0; 
N : INTEGER := 0; 
AVE TIME : FLOAT; 
START STAMP: CALENDAR. TIME; 
TIMER = DURATION := 0.0; 
LOT TIME- = DURATION := 0.0; 
CUTL TIME ~: DURATION := 0.0; 
begin 
MAIN: loop 
accept OUTPUT (SCREEN MESSAGE: in MESSAGE FORM) do 
OUT2SCREEN := SCREEN MESSAGE; 
end OUTPUT: 


case OUT2SCREEN.MESSAGE CODE is 

when 11 => 
iio seul bint sl Mainenarthe program finished." ); 
PRINT MESSAGE (OUT2SCREEN) ; 
exit: 

when 20 => 
LOCALS (OQUT2SCREEN.ORIGIN) := 
DOCS (OUIZSCREEN.ORIGIN) + 1; 


LO 


TOT_TIME := TOT_TIME + OUT2SCREEN PY oMEmo ties 
Ni No. 1: 
when 21 => 


LOCALS (OULZs 


CREEN.ORIGIN) := 


LOCALS (OUT2SCREEN.ORIGIN) = aie, 


when 30 => 

START STAMP >= CEOC.. 
when 31 => 

TIMER := CLOCK — START USTAMe. 

OUT_TIME := OUT2SCREEN. TIMED STAME: 
when 71 => 

TEXT IO.PUT LINE(" Vehicle Sys “3F 
when 72 => 

TEAL 1O.PUT LENE sO tas sige 
when 73 => 

TEXT 10.PUT LINE(” Navigatwionss 
when 74 => 

TEAL 10. PUT SEINE ( * (Mente rm, 
when 75 => 

TEXT 10.PUT LINE(" Avoidance “)); 
when 76 => 

TEXT 10,PUT LINE(” Exe Missivoeneery 
when 77 => 

TEAT TO. PUT LINE(* GCuidances 
when 78 => 

TEXT 10.PUT LINE(* Aute eR iler was 
when 99 => 


TEXT I0O.PUT LINE("Shutdewn Received: 
when others => 
TEXT_IO.PUT_LINE ("Bad MESSAGE CODE. 
end case; 
end loop MAIN; 


TEXT IO.PUT ("EARTH MAIN = "); 
INT_IO.PUT (LOCALS(EARTH_MAIN)); 
TEXT IO.NEW LINE; 


TEXT IO.PUT("TASK VEHICLE SYS = "); 
INT _IO.PUT(LOCALS(TASK VEHICLE _SYS)); 


TEXT en, 
Text oO: 
TIME _IO. 
TeX TE1O- 


UpOP aL 18 


NEW_LINE; 


PUT ("Total time from SCREEN was 
BUT (OUD TIME \; 
NEW_LINE; 


")y 
a 


ry 


PUT ("Ave Time calculated from VEHICLE SYS was 


a 
AVE_TIME := FLOAT(TOT TIME) / FLOAT(N); 
FLY _1O.PUY, AVE PM 
TEAL f0.NEW LINE; 
end SCREEN; 
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procedure PRINT_HEADER is 


begin 
TEXT I0.PUT LINE( “Please, Sieoese one Of options; ! to 4) 
below"); 
To. ere PU Tae ENE (” 1)Ring Counter Clockwise"); 
TEXT IO.PUT_LINE(" 2)Ring Clockwise"); 
Ree PelOseuUr EINE S Rana owe Mil tipakh 5 
THXTelO. PUT CLINE ( 4)Best Path"); 


end PRINT_HEADER; 
procedure PRINT QUERY is 


begin 
TEXT IO.NEW_LINE; 
TEXT 1O;PUT LinNE( Please, Enter the repetition period 
Mien Val. 9); 

Cnc sPRINTSOUERY; 


function CHECK MASK(MASK: MASK TYPE) return BOOLEAN is 


begin 
Pore MASh range loop 
if MASK(I) = FALSE then 
return FALSE; 
end if; 
end loop; 
ieee) WRB: 
end CHECK_MASK; 


-- main program 

begin 
PRINT HEADER; 
GET(CONFIG OPTION); 
case CONFIG OPTION is 


when 1 => 

FIRST MESSAGE.ROUT_INFO ;:= CNT _CLK_ RING; 
when 2 => 

FURST OMESSAGE. ROUT INFO :— CLK RING; 
when 3 => 


FIRST_MESSAGE.ROUT_INFO 
when 4 => 
FIRST MESSAGE .ROUT_INFO 
when others => 
raise CONSTRAINT ERROR; 
end case; 
Ped QUERY ; 
TIME I0.GET(SECOND_MESSAGE.PERIOD_INFO); 


MULT? PATH; 


BEST PATH; 


SeNriG TO-WRITE(OQutToMars, FIRST MESSAGE) ; 
CONFIG IO.READ(InFromMars, FIRST_MESSAGE) ; 
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ale CHECK MASK(FIRST_MESSAGE.MASK) = FALSE then 
raise MESSAGE ERROR; 
end: 15; 


PERIOD_IO.WRITE(OutToMars, SECOND MESSAGE); 

PERIOD IO.READ(InFromMars, SECOND MESSAGE); 

if CHECK_MASK(SECOND_MESSAGE.MASK) = FALSE then 
raise MESSAGE ERROR; 


end if; 
QUIT TIME >= ChOCK +) Outre INT, 
MAIN TALK.DESTIN := TASK SCREEN; 
MAIN TALK.ORIGIN := EARTH MAIN; 
MAIN TALK.MESSAGE CODE := 21; 
EARTH QUE.TO QUE (MAIN TALK); 
loop 

TIMEOUT #= CLOCK 4+ READIINT. 


MESSAGE _IO.READ _OR_FAIL (InFromMars, IN MESSAGE, 
TIME OUT, ABORTED); 
if ABORTED then 


FAILED >=. PATUED +) 1; 

else 
MESS COUNT := MESS COUNT + 1; 
IN_MESSAGE.PROG(1) := IN_MESSAGE.PROG(1) + 1; 
EARTH _QUE.TO QUE(IN_MESSAGE); 

end if; 


exit when CLOCK > OUIT TIME; 


end loop; 

MAIN TALK := IN MESSAGE; 

MAIN TALK.DESTIN := TASK_SCREEN; 
MAIN TALK.MESSAGE_CODE := 11; 
MAIN TALK.CODE_ 1 := FAILED; 

MAIN TALK.CODE 2 := MESS COUNT; 


EARTH QUE.TO QUE (MAIN TALK); 


end EARTH; 


3. PRINTOUT.ADA 


with COMMON; 
use COMMON; 
with TEXT_IO; 
package PRINTOUT is 


package PRINT_TASK is new 
TEXT_IO.ENUMERATION_ IO (TASKS) 5 
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package PRINT PROG is new TEXT_IO.ENUMERATION_IO 

(PROGRAMS) ; 

package INT_IO is new TEXT_IO.INTEGER_IO(INT_16); 

procedure PRINT_MESSAGE (MESSAGE : in MESSAGE_FORM); 
end PRINTOUT; 


package body PRINTOUT is 


procedure PRINT_MESSAGE (MESSAGE : in MESSAGE_FORM) is 


TO TASK NAME TASKS: we 
FROM_TASK_NAME :; TASKS ; 
i : INTEGER; 
begin 
FROM_TASK_NAME := MESSAGE.ORIGIN : 


TEXT IO.NEW_LINE; 
Pex TIO. PUTO LINE 


ee ee ee ee 
BR ERROR a eas Sos ted 


rete vO. PUT LINE ** Message Renere 


ee 
TEXT IO.PUT LINE ("* 


te 
7 


BEAT TO. PUT = Gem eee iy 

PRINT TASK.PUT (FROM TASK NAME,37) ; 

AEX TO. PUT LINE (a? *") > 

eet elO. PUT LINE 47 * Path Array: 


seeder 


Tan T ero. PUT ("+"): 


Peale. NUM PATHS loop 
TXT. LO. PUT (" + 
INT IO.PUT (INT _16 (MESSAGE.PATH(I)),3); 
end loop; 
Text tO.PUT LINE ¢" *"); 
eee tO. PUT GINE (” * Program Array: 


a 


f 
TEXT IO.PUT ("* Hye 


Poeeetin Lt. NUM PROGS Loop 
iP herOrMPUT (% \. 
INT IO.PUT (INT 16 (MESSAGE.PROG(I)),3); 
ia IG) em! Gt Oye 


end loop; 

text TOePUT LINE (% neues 
iuxrelo. PUT (2 eOWeelC ct " \3 

PTT TOs PUT (MESSAGE. Reopen. Voy 
aap ae 160. FUT cS CODEN 2+: "y; 
INT_IO.PUT (MESSAGE.CODE 2,3); 

TEXT IO. PUT CO Message Codey jy 


GOS 


INT IO.PUT (MESSAGE.MESSAGE_ CODE); 
TEXT TO. PUT ba Ne ey 
TEXT IO.PUT LINE 


(OI IOI I I III ICI III kk 
KEKKKKKKEKKKKKKKEKKEKKEK" Ee 


end PRINT MESSAGE; 
end PRINTOUT; 
Cc. AUV FLOW MAIN ADA PROGRAMS 
1. MARS.ADA 

with COMMON; 

use COMMON; 

with CHANNELS; 

with CALENDAR; 

use CALENDAR; 

with COMLAYER; 


procedure MARS is 


IN MESSAGE : MESSAGE FORM; --input message 

FIRST MESSAGE : CONFIG MESSAGE; --initialization message 
--that contains the chosen routing strategy 

SECOND MESSAGE : PERIOD MESSAGE; --initialization message 


--that contains the interval of repetition for the 
--AUV flow execution 


LOCATION : constant PROGRAMS >= MARS; --local 
==pLOcéssomare 

STOPPER : constant INTEGER := 100; --number of 

--loop iterations to be run by the AUV flow simulation 

NUMBER_OF_INPUTS: constant NATURAL := 3; --number of used 

--communication channel inputs 

WHICH_CHANNEL: INTEGER; -— returnedgby the scala. 


--primitive READ of the package CHANNELS 
--indicating from which channel the message comes in. 
NUMBER_OF_ OUTPUTS: constant NATURAL := 3; --number of used 
--communication channel outputs 
--This task receives PILOT_UPDATE message from task 
=- Ven tel wo YS sane 
--AP_ORDERS message from task GUIDANCE and sends VS_ORDERS 
--message to task VEHICLE SYS 
task AUTO PILOT is 
entry AP ORDERS (PILOT MESSAGE : in MESSAGE FORM); 
entry PILOT UPDATE (PILOT MESSAGE : in MESSAGHRRGE ay 
end; 
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--This task controls the frequency of execution of the AUV 
--flow.It receives the period interval to be used from 
--main program MARS during initialization. 
task TIMER is 

entry SET _TIMER(SET_ PERIOD: in DURATION); 
end; 


--This task accepts message GO from from task TIMER and 
--message VS_ORDERS from task AUTO_PILOT and sends 
--message Ss olaAlUSse tO cask NAVIGATION, message 
--UPDATE_SONAR to task SONAR, message TO MONITOR to task 
--MONITOR and message PILOT_UPDATE to task AUTO_PILOT. 
--The entry FIN is not used in this implementation. 
task VEHICLE SYS is 
entry VS_ORDERS (VS_MESSAGE : in MESSAGE FORM) ; 
Sciane (EG) : 
enery FIN 
end; 


--communication channels that are used 
OutToEarth >: CHANNELS.CHANNEL_ REF := 
CHANNELS.OUT_ PARAMETERS (2); 
InFromEarth : CHANNELS.CHANNEL REF 
CHANNELS.IN_ PARAMETERS (2); 
InFromVenus : CHANNELS.CHANNEL REF := 
CHANNELS.IN_ PARAMETERS (4); 
OutToVenus : CHANNELS.CHANNEL REF := 
CHANNELS.OUT_ PARAMETERS (4); 
InFromPluto : CHANNELS.CHANNEL REF := 
CHANNELS.IN_ PARAMETERS (5); 
GOutLToPluto : CHANNELS.CHANNEL REF := 
CHANNELS .OUT_PARAMETERS (5); 


--Array that contains the input communication channels. 
--This array isused by the call to primitive READ of the 
--package CHANNELS. 

MARS ARRAY: CHANNELS.CHANNEL ARRAY(0..NUMBER_OF_INPUTS-1) 
:= (InFromEarth, InFromVenus, InFromPluto); 


--This array enables each input communication channel 

--individually for use with primitive READ of package 

--CHANNELS.It is associated with MARS ARRAY. 

MARS GUARD: CHANNELS.GUARD ARRAY(0..NUMBER_OF INPUTS-1) := 
(TRUE, TRUE, TRUE);--all input channels are 

--enabled 

ea Sbay ella CONtains the output Communication channels 

--OUT_ ARRAY: 

CHANNELS .CHANNEL_ ARRAY(0..NUMBER_OF_OUTPUTS-1) := 
(OutToEarth, OutToVenus, OutToPluto); 


Oi 


~-Table that defines the routing strategy to be used. The 
-~-type OUT_TABLE is defined in package COMMON. 

MARS TABLE: OUT_TABLE(EARTH..PLUTO, 

0..NR_OF OUTPUTS (MARS)-1); 


--This procedure is used for the instantiation of the 

~-package COMLAYER. It is used by task QUE in package 

--COMLAYER when sending messages to local tasks AUTO_PILOT 

--and VEHICLE SYS. 

procedure SEND _IT_FROM MARS (MESSAGE : in MESSAGE_FORM; 
MESS : out BOOLEAN) is 


MESSAGE SENT : BOOLEAN := FALSE; 


begin 
case MESSAGE.DESTIN is 
when TASK_AUTO_ PILOT => 
case MESSAGE.ENT CALL is 
when AP_ORDERS => 


select 
AUTO_PILOT.AP_ORDERS (MESSAGE); 
MESSAGE_SENT := TRUE; 

or 
délay 0.0, 


end select; 
when PILOT UPDATE => 
select 
AUTO_PILOT.PILOT UPDATE (MESSAGE); 
MESSAGE SEND :— TRUER, 
one 
delay 020; 
end select; 
when others => null; --Not a valid call 
end case; 
when TASK_TIMER => 
case MESSAGE.ENT_CALL is 
when others => null; --Not a valid call 
end case; 
when TASK VEHICLE SYS => 
case MESSAGE.ENT_CALL is 
when VS_ORDERS => 
select 
VEHICLE_SYS.VS_ORDERS (MESSAGE); 
MESSAGE SENT := TRUE; 
or 
delay70).0 ; 
end select; 
when others => null; --Not a valid call 
end case; 
when others => null; --Not a valid task 
end case; 
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MESS := MESSAGE_ SENT; 
return; 
end SEND_IT_FROM_MARS; 


--instantiates the package for communication layer. 
package MARS LAYER is new COMLAYER(SEND_IT_FROM_MARS); 
use MARS _ LAYER; 


task body AUTO_PILOT is 
Je IES O I Ne > constant DURATION := 0.04; 
IN_TASK, NEW_SYS, TALK : MESSAGE FORM; 


OPEN1: BOOLEAN := TRUE; 
OPEN2: BOOLEAN := TRUE; 
begin 
loop 
while (OPEN1 or OPEN2) loop 


Se leee 
when OPEN1 => . 
accept PILOT_UPDATE (PILOT_MESSAGE : in 
MESSAGE FORM) do 
NEW SYS := PILOT MESSAGE; 
OPEN] := FALSE; 
end PILOT _UPDATE; 
or 
when OPEN2 => 
accept AP_ORDERS (PILOT MESSAGE : in 
MESSAGE _FORM) do 


INE TAS: — §P1 LOT MESSAGE; 
OPEN2 := FALSE; 
end AP ORDERS; 
Om 
terminate; 


end select; 
end loop; 


OPEN1 
OPEN2 


TRUE; 
TRUE; 


delay PILOT INT; 

IN_TASK.ORIGIN TASK AUTO PILOT; 
IN_TASK.DESTIN TASK_SCREEN; 
iNeTiskKeoNPeCALL <= OUTPUT: 
IN_TASK.MESSAGE CODE := 78; 
--INOUT.SEND(IN_TASK); -- debugging message 


IN_TASK.ORIGIN SS TENS JAUMUON SILO al 
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IN_TASK.DESTIN 7= TASK VEHTI@GEE Sve, 


IN TASK.ENT_CALL := VS_ORDERS; 
INOUT.SEND (IN_TASK); 
end loop; 


end AUTO_PILOT; 


--This task controls the frequency of execution of the 
--AUV flow.It receives the period interval to be used 
--from main program MARS 

=-GUFING Initializar ven, 

task body TIMER is 


COUNT ; INTEGER := 0 ; 
TALK : MESSAGE FORM; 

NEXT_TIME: CALENDAR.TIME; 
INTERVAL: DURATION; 


begin 
accept SET TIMER(SET PERIOD: in DURATIGN mde 
INTERVAL <= SET PERIOD: 
end SET TIMER; 
NEXT_TIME := CALENDAR.CLOCK; 
loop 


delay NEXT_TIME - CALENDAR.CLOCK; 
VEHICLE 875.60; 


COUNT := "COUNT + 1; 

exit when COUNT = STOPPER; 

NEXT _ TIME := NEXT TIME + INTERVAL; 
end loop; 
delay 3.0; 
TALK = SHUTDOWN_MESSAGE; 
TALK.DESTIN = LOOP TASK; 
TALK.MESSAGE CODE := 99; 


INOUT.SEND (TALK); 


end TIMER; 


task body VEHICLE SYS is 


VEHICLE INT : constant DURATION. ;=—s07037 
IN TASK, TALK : MESSAGE FORM; 
NEXT_TIME : CALENDAR.TIME := CLOCK Pay ERT Graal 
PRE STAMP : CALENDAR. TIME; 
START STAMP : CALENDAR.TIME; 
TIMER : DURATION; 
FINAL : DURATION; 
COUNT : INTEGER: —— G; 
begin 


PRE STAMP := CLOCK; 
TALK.ORIGIN 
TALK. DESTIN 


TASK VEHICLE_SYS; 
TASK SCREEN ; 


TALK. ENT_CALL OuUTPUL - 
TALK .MESSAGE CODE 0 . 
INOUT.SEND (TALK); 
oo. 
select 
acecepe GO, 
START STAMP := CLOCK; 


delay VEHICLE_INT; 


IN_TASK.ORIGIN 
IN_TASK.DESTIN 


TSK VEHICLE SYS; 
TASK_SCREEN; 


INSTASK. ENT CALL i= OUTPUT; 
IN TASK.MESSAGE_CODE := 71; 
--INOUT.SEND (IN_TASK); -- debugging message 


IN_TASK.ORIGIN 
IN_TASK.DESTIN 


TASK _VEHICLE_SYS; 
TASK NAVIGATION ; 


IN TASK.ENT_ CALL = 00S Sones : 
INOUT.SEND (IN_TASK); 

IN_TASK.ORIGIN := TASK VEHICLE SYS; 
IN_TASK.DESTIN = TASK SONAR ; 
IN_TASK.ENT_CALL := UPDATE_SONAR ; 


INOUT. SEND (IN_ TASK); 


IN_TASK.ORIGIN 
IN_TASK. DESTIN 
IN_TASK.ENT CALL 
INOUT.SEND (IN_TASK); 


TASK_VEHICLE_SYS; 
TASK MONITOR : 
TO MONITOR ; 


IN_TASK.ORIGIN 
IN_TASK.DESTIN 
IN_TASK.ENT CALL 
INOUT.SEND (IN TASK); 


TASK_VEHICLE_SYS; 
TASK AUTO PILOT ; 
PILOT UPDATE ; 


aecepe VSTORDERS (VS MESSAGE : in MESSAGE FORM) do 
IN_TASK := VS_MESSAGE; 
end vs TORDERS; 


TIMER CLOCK ~ START STAMP; 
COUNT COUNT + 1; 
TALK.ORIGIN 
TALK . DESTIN 
TALK.ENT_CALL 
TALK.TIME STAMP 


TASK VEHICLE_SYS; 
TASK SCREEN ; 
OUTPUT : 
TIMER ; 


yy 


TALK.MESSAGE CODE := 20 : 
INOUT- SEND RerALE y 


exit when COUNT = STOPPER; 


or 
aceccor © IN; 
exit; 
end select; 
end loop; 
FINAL += CLOCK — PREVSLTAME, 
TALK.ORIGIN ;= TASK VEHICUENS Ys: 


TALK. DESTIN 


TASK SCREEN ; 


TALK. ENT CALL = OUTPUT : 
TALK. TIME STAMP = FINAL ‘ 
TALK «MESSAGE CODE <= 31 : 


INOUT. SEND {TALK 
end VEHICLE Sys; 


begin 


--reads the routing strategy initialization message 
CONFIG TO.READ(InNFromBareh, FIRST MESSAGE), 
FIRST_MESSAGE.MASK(MARS) := TRUE; 

--passes the routing strategy message to PLUTO 
CONFIG IO.WRITE(OutToPluto, FIRST MESSAGE) ; 


-~-reads the routing strategy message from VENUS and sends 
--it back to EARTH 

CONFIG IO.READ(InFromVenus, FIRST MESSAGE); 

CONFIG IO.WRITE(OUutToOERarth, FIRST MESSAGE): 


--reads the period interval initialization message 
PERIOD_IO.READ(InFromEarth, SECOND MESSAGE) ; 
SECOND MESSAGE.MASK(MARS) := TRUE; 


--passes the period interval message to PLUTO 
PERIOD I1O.WRITE(OutToOPluto, SECONDEMESSACcia: 


--reads the period interval message from VENUS and sends 
--it back to EARTH 

PERIOD _IO.READ(InFromVenus, SECOND MESSAGE) ; 

PERIOD IO.WRITHE(QutTokarth, SECOND MESSAGE yy 


~-initialize the routing strategy table 
MARS TABLE := MARS CONFIG(FIRST MESSAGE.ROUT_ INFO); 


--set the timer with the period interval 
TIMER.SET_TIMER(SECOND_MESSAGE.PERIOD_ INFO); 


Is 


tm cmwalization Of task INOUT 


INOUT.INIT1( LOCATION) ; --main node program ID 
PGi = it OUMARRAY 5 —-OUEDUL Channel array 
INOUT.INIT3(MARS_ TABLE); --routing table 

loop 


--Reads message from a input channel 
MESSAGE_IO.READ(MARS ARRAY, MARS GUARD, WHICH _CHANNEL, 


IN MESSAGE); 


--Increments MARS counter in the PROG(2) message field 
IN MESSAGE.PROG(2) := IN _MESSAGE.PROG(2) + 1; 


--if a shutdown message has arrived exit the loop 
if IN _MESSAGE.ORIGIN = SHUTDOWN and IN _MESSAGE.DESTIN 
= HOST TASK then 


IN _MESSAGE.PROG(2) := -1 * IN _MESSAGE.PROG(2); 
clea yarlevs 
INOUT. INCOMING (IN_MESSAGE) ; 
exit; 
end if; 


--sends input message to the traffic handler 
INOUT. INCOMING (IN MESSAGE); 


end loop; 


end MARS; 


with 
use 
with 
with 
use 
with 


2. PLUTO.ADA 


COMMON; 
COMMON ; 
CHANNELS; 
CALENDAR; 
CALENDAR; 
COMLAYER; 


procedure PLUTO is 


use COMMON; 

use CALENDAR; 

IN MESSAGE : MESSAGE FORM; --input message 

FIRST MESSAGE : CONFIG MESSAGE; --initialization message 


--that contains the chosen routing strategy 


ies 


SECOND MESSAGE : PERIOD _ MESSAGE; --initialization message 
--that contains the interval of repetition of the 
--AUV flow execution 


LOCATION ; constant PROGRAMS = PLUTO; --local 
~-processor ID 

NUMBER_OF_INPUTS: constant NATURAL = 2; --number of 
--used communication channel inputs 

WHICH _ CHANNEL : INTEGER; --returned by thevcaliees 


--primitive READ of package CHANNELS indicating from 
--which channel the message comes in. 
NUMBER_OF_OUTPUTS: constant NATURAL := 2; --number of used 
--communication channel outputs 
--This task receives message MONITOR_UPDATE from task 
--MONITOR and message OBJECT_ALERT from task AVOIDANCE. It 
--sends message UPDATE ORDERS to task GUIDANCE. 
task EXE MISSION is 
entry OBJECT ALERT (EXE_MESSAGE : in MESSAGE FORM); 
entry MONITOR_UPDATE (EXE_MESSAGE : in MESSAGE FORM); 
end; 


--This task receives message TO MONITOR from task 
-~-VEHICLE_SYS and sends message MONITOR_UPDATE to task 
=-EAE Missron 
task MONITOR is 

entry TO MONITOR (MON MESSAGE : in MESSAGE_FORM); 
end; 


-- communication channels that are used 
OutTosaturn : CHANNELS.CHANNEL REF <= 
CHANNELS .OUT_PARAMETERS (4); 
InFromSaturn: CHANNELS.CHANNEL REF := 
CHANNELS.IN_ PARAMETERS (4); 


InFromMars : CHANNELS.CHANNEL REF := 
CHANNELS.IN_PARAMETERS (3); 
OutToMars : CHANNELS.CHANNEL_ REF := 


CHANNELS.OUT_PARAMETERS (3); 


--Array that contains the input communication channels. 
--This array is used by the call to primitive READ of 
--package CHANNELS. 

PLUTO ARRAY: CHANNELS.CHANNEL ARRAY(0..NUMBER_OF_INPUTS-1) 
:= (InFromSaturn, InFromMars); 


--This array enables each input communication channel 
--individually 

--for use with primitive READ of package CHANNELS. 
--It is associated with PLUTO_ARRAY. 
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PLUTO GUARD: CHANNELS.GUARD_ARRAY(0..NUMBER_OF_INPUTS-1) 
:= (TRUE, TRUE); 


= tudyeenae= Conucains Lhe OUEpuE communication channels 
--OUT_ARRAY: 
CHANNELS.CHANNEL ARRAY(0..NUMBER_OF_OUTPUTS-1) := 

(Gut ToMars,. Ourlosaturn), 


--Table that defines the routing strategy to be used. The 
—--type 

--OUT_ TABLE is defined in package COMMON. 

PLUTO_TABLE: 

CUTS TABLE( EARTH. .~PLUTO,0..NR_OF OUTPUTS(PLUTO)-—-1); 


--This procedure is used for the instantiation of the 
--package COMLAYER. It is used by task QUE in package 
--COMLAYER when sending messages to local tasks. 
procedure SEND _IT_FROM PLUTO (MESSAGE : in MESSAGE FORM; 
MESS : out BOOLEAN) is 


MESSAGE SENT : BOOLEAN := FALSE; 
begin 
case MESSAGE.DESTIN is 
when TASK EXE MISSION => 
case MESSAGE.ENT_CALL is 
when OBJECT_ALERT => 


select 
EXE_MISSION.OBJECT_ALERT (MESSAGE) ; 
MESSAGE SENT := TRUE; 

OF 
delay 0.0; 


end select; 
when MONITOR_UPDATE => 
select 
EXE MISSION.MONITOR_ UPDATE (MESSAGE) ; 
MESSAGE SENT := TRUE; 
or 
delay 0.0; 
end select; 
when others => null; -- Not a valid call 
end case; 
when TASK_MONITOR => 
case MESSAGE.ENT_CALL is 
when TO MONITOR => 
select 
MONITOR.TO_ MONITOR (MESSAGE) ; 
MESSAGE SENT := TRUE; 
(ove 
delay 0.0; 
end select; 
when others => null; -- Not a valid call 


IES 


end case; 


when others => null; -- not a valid task 
end case; 
MESS «= MESSAGE SENT, 
GeuuEn , 


end SEND _IT FROM PLUTO; 


-- instantiates the package for communication layer 
package PLUTO LAYER is new COMLAYER(SEND IT FROM PLUTO); 
use PLUTO_LAYER; 


task body EXE _MISSION is 


begin 


EXE INT: constant DURATION := 0.06; 
TALK, IN TASK : MESSAGE FORM; 
OPEN1: BOOLEAN := TRUE; 
OPEN2: BOOLEAN := TRUE; 
loop 
while (OPEN1 or OPEN2) loop 
select 


when OPENI1 => 
accept MONITOR_UPDATE (EXE MESSAGE : in 
MESSAGE FORM) do 


IN TASK := EXE _MESSAGE; 
OPEN1 := FALSE; 
end MONITOR_UPDATE; 
or 
when OPEN2 => 
accept OBJECT ALERT (EXE MESSAGE : in 
MESSAGE FORM) do 
IN_ TASK := EXE MESSAGE; 
OPEN2 := FALSE; 
end OBJECT ALERT; 
or 
terminate; 
end select; 
end loop; 
OPEN1 := TRUE; 
OPEN2 := TRUE; 
delay EXE INT; 
IN_TASK.ORIGIN := TASK_EXE MISSION; 
TN TASK.DESTIN := TASK SCREEN; 
ine TASK.ENT _ CALL <= OUTPUT; 
IN _TASK.MESSAGE CODE := 76; 


ILL 


--INOUT.SEND (IN_TASK); debugging message 


IN_TASK.ORIGIN 
IN_TASK.DESTIN 
IN_TASK.ENT_CALL 
INOUT.SEND (IN_TASK); 


TASK EXE MISSION; 
TASK GUIDANCE; 
UPDATE ORDERS; 


end loop; 
end EXE MISSION; 


oii tasnehecel Ves message TO MONITOR from task 
--VEHICLE SYS and sends message MONITOR_UPDATE to task 
-~-EXE_ MISSION 

task body MONITOR is 


MONGTOR TINT: constant DURATION ;= 0.03; 
IN_TASK, TALK : MESSAGE FORM; 
begin 
loop 
Select 
accept TO_MONITOR (MON_MESSAGE : in MESSAGE FORM) 
do 
IN_TASK := MON_MESSAGE; 


end) 10) MONITOR; 
delay MONITOR_INT; 


PNETASK- ORIGIN TASK MONITOR; 
IN_TASK.DESTIN TASK_SCREEN; 

PN Task ENT Canis: OUTPUT; 
IN_TASK.MESSAGE CODE := 74; 

-- INOUT.SEND( IN_TASK); -- debugging message 


IN_TASK. DESTIN 
IN_TASK.ORIGIN 
IN_TASK.ENT_ CALL 


TASK_EXE_ MISSION; 
TASK_MONITOR; 
MONITOR_UPDATE; 


INOUT.SEND (IN TASK); 
or 
terminate; 
end select; 
ene sloop, 


end MONITOR; 
begin 


--reads the routing strategy initialization message 
CONFIG IO.READ(InFromMars, FIRST_MESSAGE); 


Hele? 


FIRST _MESSAGE.MASK( PLUTO) := TRUE; 


--passes the routing strategy message to SATURN 
CONFIG_IO.WRITE(OutToSaturn, FIRST MESSAGE); 


--reads the period interval initialization message 
PERIOD I0O.READ(InFromMars, SECOND MESSAGE); 
SECOND MESSAGE.MASK(PLUTO) := TRUE; 


--passes the period interval message to SATURN 
PERIOD 10.WRITE(OUETOSatCurn, SECONDIMESS2 cre 


--initialize the routing strategy table 


PLUTO TABLE := PLUTO CONFIG(FIRST_MESSAGE.ROUT INFO); 
--initialization of task INOUT 

INQUT. INITI( LOCATIGN }; -- main node program ID 
INOUD. INID2 OUTTAR RAs -- output channel array 
INOUT.INIT3(PLUTO_ TABLE); -- routing table 

loop 


--Reads message from a input channel 
MESSAGE _I0.READ(PLUTO_ ARRAY, PLUTO GUARD, WHICH_CHANNEL, 
IN_ MESSAGE); 


--increments PLUTO counter in PROG(5) message field 
IN MESSAGE.PROG(5) := IN MESSAGE.PROG(5) + 1; 


--if a shutdown message has arrived exit the loop 
if IN_MESSAGE.ORIGIN = SHUTDOWN then 


IN_MESSAGE.DESTIN >= HOST_TASK; 
IN MESSAGE.PROG(5) := -l1 * IN _MESSAGE.PROG(5); 
INOUT. INCOMING (IN_MESSAGE); 
exit; 
end) a i 


--sends input message to the traffic handler(task INOUT) 
INOUT.INCOMING (IN MESSAGE); 
end loop; 
end PLUTO; 


3. SATURN.ADA 


with COMMON; 
use COMMON; 
with CHANNELS; 
with CALENDAR; 
use CALENDAR; 
with COMLAYER; 


i 


procedure SATURN is 


IN_MESSAGE : MESSAGE FORM; -- inputmessage 

FIRST MESSAGE : CONFIG MESSAGE; --initialization message 
--that contains the chosen routing strategy 

SECOND MESSAGE : PERIOD MESSAGE; --initialization message 
--that contains the interval of repetition of the 

--AUV flow execution. 

LOCATION : constant PROGRAMS := SATURN; --local 
--processor ID 


NUMBER_OF_INPUTS: constant NATURAL := 2; -- number of 
--used communication channels inputs 
Wo lenwerANNEIL se GRGER; —— returned by the call to 


--primitive READ of package CHANNELS indicating from 

--which channel the message comes in. 

NUMBER_OF OUTPUTS : constant NATURAL := 2; --number of 
--used communication channels output. 


task AVOIDANCE is 


entry OB AVOID (AVOID MESSAGE : in MESSAGE _ FORM); 
end; 


task GUIDANCE is 


entry UPDATE NAV (GUIDE_MESSAGE : in MESSAGE _ FORM); 

entry UPDATE_ORDERS (GUIDE_MESSAGE : in MESSAGE FORM); 

entry AVOID REC (GUIDE MESSAGE : in MESSAGE FORM); 
end; 


-- communication channels that are used 
OutToVenus > CHANNELS.CHANNEL_REF := 
CHANNELS .OUT_PARAMETERS (3); 
InFromVenus : CHANNELS.CHANNEL REF 
CHANNELS.IN_ PARAMETERS Cae 
InFromPluto : CHANNELS .CHANNEL REF 
CHANNELS.IN PARAMETERS (2); 
OutToPluto > CHANNELS.CHANNEL_ REF 
CHANNELS .OUT_PARAMETERS (2); 


--Array that contains the input communication channels. 
--This array is used by the call to primitive READ of 
--package CHANNELS. 

SATURN_ARRAY: 

CHANNELS .CHANNEL_ARRAY(0..NUMBER_OF_INPUTS-1) i= 
(InFromVenus, InFromPluto); 


--This array enables each input communication channel 
--individually 

--for use with primitive READ of package CHANNELS. 

--It is associated with SATURN_ARRAY. 
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SATURN_GUARD: CHANNELS.GUARD_ARRAY(0..NUMBER_OF_INPUTS-1) 
:= (TRUE, TRUE); 


--Array that contains the output communication channels 

OUT_ARRAY: 
CHANNELS.CHANNEL_ARRAY(0..NUMBER_OF_OUTPUTS-1) 

:= (OutToVenus, OutToPluto); 


--Table that defines the routing strategy to be used. The 
--type OUT_TABLE is defined in package COMMON 

SATURN TABLE: OUT_TABLE(EARTH..PLUTO, 
0..NR_OF OUTPUTS(SATURN)-1); 


--This procedure is used for the instantiactionsoreen 
--package COMLAYER. It is used by task QUE in package 
--COMLAYER when sending messages to local tasks. 

procedure SEND_IT_FROM SATURN (MESSAGE : in MESSAGE FORM; 

. MESS : out BOOLEAN) is 


MESSAGE_SENT :; BOOLEAN := FALSE; 


begin 
case MESSAGE.DESTIN is 
when TASK _AVOIDANCE => 
case MESSAGE.ENT CALL is 
when OB_AVOID => 


select 
AVOIDANCE.OB_ AVOID (MESSAGE); 
MESSAGE SENT := TRUE; 

one: 
delay 0.0; 

end select; 

when others => null; == not a valid car 
end case; 


when TASK GUIDANCE => 
case MESSAGE.ENT_CALL is 
when UPDATE_NAV => 


select 
GUIDANCE.UPDATE_NAV (MESSAGE) ; 
MESSAGE _SENT := TRUE; 

or 
delay 0.0; 


end select; 
when UPDATE ORDERS => 


select 
GUIDANCE.UPDATE_ORDERS (MESSAGE); 
MESSAGE SENT -— TRUE, 

or 
delay.0.0. 


end select; 
when AVOID REC => 
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select 
GUIDANCE .AVOID_REC (MESSAGE); 
MESSAGE SENT := TRUE; 

ou 
delay 0.0; 

-end select; 

when others => null; -- Not a valid call 
end case; 
when others => null; -- not a valid task 
end case; 


MESS := MESSAGE SENT; 
eee ie 
end SEND IT FROM SATURN; 


--instantiates the package for communication layer 


package SATURN_LAYER is new COMLAYER(SEND_IT_FROM SATURN); 
use SATURN_LAYER; 


task body AVOIDANCE is 


AVOIDANCE _INT: constant DURATION := 0.08; 
TALK, IN TASK : MESSAGE_FORM; 
begin 
loop 
select 
accept OB AVOID (AVOID MESSAGE : in MESSAGE FORM) do 


IN TASK := AVOID MESSAGE; 
end OB AVOID; 


delay AVOIDANCE_INT; 


IN_TASK.ORIGIN := TASK_AVOIDANCE; 
IN_TASK.DESTIN >= TASK SCREEN; 

DN OTASK. ENT CALL <= OUTPUT; 

IN TASK.MESSAGE CODE := 75; 

-- INOUT.SEND( IN TASK); -- debugging message 


IN_TASK.ORIGIN TASK AVOIDANCE ; 
IN_TASK.DESTIN TASK GUIDANCE ; 
IN TASK.ENT_ CALL := AVOID _REC ; 
INOUT.SEND (IN_TASK); 


IN_TASK.ORIGIN TASK AVOIDANCE ; 
IN_TASK.DESTIN TASK _EXE_MISSION; 
IN TASK.ENT CALL := OBJECT ALERT ; 
INOUT.SEND (IN_TASK); 


OF 
terminate; 
end select; 
end loop; 


end AVOIDANCE; 


task body GUIDANCE is 


GUIDANCE INT: constant DURATIONS. — C707. 

EMERG, IN_TASK, GO_TO, WE_ARE, TALK : MESSAGE FORM; 
OPENI: BOOLEAN := TRUE; 

OPEN2: BOOLEAN := TRUE; 

OPEN3: BOOLEAN TRUE 


begin 
loop 


while (OPEN1 or OPEN2 or OPEN3) loop 
Selec: 
when OPENI1 => 
accept UPDATE NAV (GUIDE MESSACHE = im 
MESSAGE FORM) do 
WE_ARE := GUIDE_MESSAGE; 
OPENL :=] PALSE; 
end UPDATE_NAV; 
Or 
when OPEN2 => 
accept AVOID_REC (GUIDE_MESSAGE : in 
MESSAGE FORM) do 
GO TO := GUIDE MESSAGE; 
OPENZ := FALSE} 
end AVOIESREC: 


OG 
when OPEN3 => 
accept UPDATE_ORDERS (GUIDE_MESSAGE : sigh 
MESSAGE FORM) do 


GO_TO := GUIDE MESSAGE, 
OPEN3 := FALSE; 
6nd UPDATE VORDERS, 
or 
terminate; 


end select; 
end loop; 


OPEN1 := TRUE; 
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OPEN2 
OPEN3 


TRUE; 
TRUE; 


delay GUIDANCE_INT; 


IN_TASK.ORIGIN 
IN_TASK.DESTIN 


TASK GUIDANCE; 
TASK SCREEN; 


IN TASK.ENT_CALL = Omen: 
IN TASK.MESSAGE CODE := 77; 
--INOUT.SEND(IN_TASK); -- debugging message 


IN_TASK.ORIGIN 
IN_TASK. DESTIN 
IN_ TASK.ENT_ CALL 
INOUT. SEND (Ca TASK); 
end loop; 


TASK GUIDANCE ; 
TASK_ AUTOS E TLOT: 
AP _ ORDERS ; 


end GUIDANCE; 
begin 
--reads the routing strategy initialization message 
CONFIG_IO.READ(InFromPluto, FIRST _MESSAGE); 
FIRST MESSAGE .MASK(SATURN) := TRUE; 


--passes the routing strategy to VENUS 
CONFIG IO.WRITE(OutToVenus, FIRST MESSAGE); 


--reads the period interval initialization message 
PERIOD_IO.READ(InFromPluto, SECOND MESSAGE) ; 
SECOND _ MESSAGE. MASK(SATURN) := TRUE; 


--passes the period interval message to SATURN. 
PRR tOperO.WRITE(OutTOVenus, SECOND MESSAGE); 


--initialize the routing strategy table 


SATURN_TABLE := SATURN_CONFIG(FIRST_MESSAGE.ROUT_INFO); 
--initialization of task INOUT 

ONOUT. INIT! (LOCATION); -- main node program ID 
miOUT.<INIT2(OUT ARRAY); -- output channel array 
ENOUT. INIT3(SATURN TABLE); -- routing table 

loop 


--Reads message from a input channel 
MESSAGE_IO.READ (SATURN ARRAY, SATURN_GUARD, 
WHICH CHANNEL, IN MESSAGE); 


--increments SATURN counter in PROG(4) message field 
IN _MESSAGE.PROG(4) := IN _MESSAGE.PROG(4) + 1; 
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--if a shutdown message has arrived exit the loop 
if IN_MESSAGE.ORIGIN = SHUTDOWN and IN MESSAGE.DESTIN = 
HOST_TASK then 


IN _MESSAGE.PROG(4) := -1 * IN MESSAGE.PROG(4); 
INOUT.INCOMING (IN MESSAGE); 
exit: 

end i+ 


--sends input message to the traffic handler(task INOUT) 
INOUT.INCOMING (IN_MESSAGE); 
end loop; 
end SATURN; 


4. VENUS.ADA 


with COMMON; 
use COMMON; 
with CHANNELS; 
with CALENDAR; 
use CALENDAR; 
with COMLAYER; 


procedure VENUS is 


IN MESSAGE : MESSAGE FORM; --input message 

FIRST MESSAGE : CONFIG MESSAGE; -- initialization message 
--that contains the chosen routing strategy 

SECOND_MESSAGE : PERIOD MESSAGE; -- initialization message 


--that contains the interval of Feperition women 
--AUV flow execution 


LOCATION : constant PROGRAMS := VENUS; --local 
--processor ID 

NUMBER_OF_INPUTS: constant NATURAL := 2; --number of 
--used communication channel inputs 

WHICH CHANNEL: INTEGER; --returned by the calice 


--primitive READ of package CHANNELS indicating from 
--which channel the message comes in. 

NUMBER_OF_OUTPUTS: constant NATURAL := 2; -- number ies 
--used communication channel outputs 


task NAVIGATION is 
entry SONAR _OBSTICLE (NAV_MESSAGE : in MESSAGE FORM); 
entry SYS STATUS (NAV_MESSAGE : in MESSAGE FORM); 
end; 


task SONAR is 
entry UPDATE SONAR (SONAR_MESSAGE : in MESSAGE FORM) ; 
end; 
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--communication channels that are used 


InFromMars >: CHANNELS.CHANNEL REF := 
CHANNELS.IN_PARAMETERS (2); 
OutToMars ; CHANNELS.CHANNEL REF := 


CHANNELS .OUT_PARAMETERS (2); 
InFromSaturn : CHANNELS.CHANNEL REF := 
CHANNELS.IN_PARAMETERS (5); 
OutToSaturn : CHANNELS.CHANNEL REF := 
CHANNELS.OUT PARAMETERS (5); 


--Array that contains the input communication channels. 
--This array is used by the call to primitive READ of the 
--package CHANNELS. 

VENUS_ ARRAY: 
CHANNELS.CHANNEL_ARRAY(0..NUMBER_OF _INPUTS-1) := 
ClnrromMars, —[InFromSaturn); 

--This array enables each input communication channel 
--individually for use with primitive READ of package 
--CHANNELS.It is associated with VENUS_ARRAY. 

VENUS _GUARD: CHANNELS.GUARD_ARRAY(0..NUMBER_OF_INPUTS-1) 
:= (TRUE, TRUE); 


-- Array that contains the output communication channels 
OUT_ARRAY: CHANNELS.CHANNEL ARRAY(0..NUMBER_OF OUTPUTS-1) 
Pn OULhotats,. GulLloOsaturn); 


--Table that defines the routing strategy to be used. The 
--type OUT_TABLE is defined in package COMMON 

VENUS TABLE: OUT_TABLE(EARTH..PLUTO, 

0..NR_OF OUTPUTS (VENUS)-1); 


--This procedure is used for the instantiation of the 
--package COMLAYER. It is used by task QUE in package 
--COMLAYER when sending messages to local tasks. 
procedure SEND _IT_FROM_VENUS (MESSAGE : in MESSAGE FORM; 
MESS : out BOOLEAN) is 


MESSAGE _SENT : BOOLEAN := FALSE; 
begin 
case MESSAGE.DESTIN is 
when TASK _NAVIGATION => 
case MESSAGE.ENT_CALL is 
when SONAR_OBSTICLE => 


select 
NAVIGATION.SONAR_OBSTICLE (MESSAGE) ; 
MESSAGE SENT := TRUE; 

Ge 
Ge lay 70.0. 


end select; 
when SYS STATUS => 
select 


UA 


NAVIGATION. SYS_STATUS (MESSAGE) ; 
MESSAGE SENT <— TRUE; 
OL 
gelay 0c; 
end select; 
when others => null; -- Not a valid call 
end case; 
when TASK SONAR => 
case MESSAGE.ENT_CALL is 
when UPDATE SONAR => 
select 
SONAR.UPDATE SONAR (MESSAGE); 
MESSAGE SENT := TRUE; 
Om 
delay 0.0; 
end select; 
when others => null; -- Not a valid call 
end case; 
when others => null; -- not a valid task 
end case; 


MESS := MESSAGE SENT; 
return; 
end SEND IT FROM VENUS; 


--instantiates the package for communication layer 
package VENUS_LAYER is new COMLAYER(SEND_IT_FROM_VENUS); 
use VENUS _ LAYER; 


--This task receives SYS STATUS message from task 
--VEHICLE SYS and SONAR _ OBSTICLE message from task SONAR. 
==Tt sends UPDATE_NAV message to task GUIDANCE. 

task body NAVIGATION is 


NAVIGATION_INT: constant DURATION := 0.05; 
SYNCsiNT ; DURATION := 0.03; 
EIN TASK, TALK +> MESSAGE FORM, 
OPEN1: BOOLEAN := TRUE; 
OPEN2: BOOLEAN := TRUE; 
begin 

lieop 

while (OPEN1 or OPEN2) loop 

Sellece 


when OPENI1 => 
accept SYS_ STATUS (NAV_MESSAGE : in 
MESSAGE _ FORM) do 
IN TASK := NAV_MESSAGE; 
OPEN1 := FALSE; 
6nd "SYS estas, 


126 


GE 
when OPEN2 => 
accept SONAR_OBSTICLE (NAV_MESSAGE : in 
MESSAGE FORM) do 
IN_TASK := NAV_MESSAGE; 
OPEN2 := FALSE; 
end SONAR_OBSTICLE; 
or 
terminate; 
end select; 
end loop; 


OPEN1 
OPEN2 


TRUE; 
TRUE; 


delay NAVIGATION_INT; 


IN_TASK.ORIGIN 
IN_TASK.DESTIN 


TASK NAVIGATION; 
TASK_SCREEN; 


nou ou 


IN TASK.ENT CALL OUTPUT; 
IN_TASK.MESSAGE CODE := 73; 
--INOUT.SEND( IN TASK ); -- debugging message 


IN_TASK.ORIGIN 

IN_TASK.DESTIN 

IN_TASK.ENT_CALL 

INOUT.SEND (IN TASK); 
Suc loop, 


-TASK NAVIGATION; 
TASK GUIDANCE; 
UPDATE NAV; 


end NAVIGATION; 


task body SONAR is 


SONAR_INT: constant DURATION := 0.02; 
TALK, IN_TASK : MESSAGE FORM ; 
EMERG MESSAGE : MESSAGE FORM ; 
begin 
loop 
Pete cre 


accept UPDATE SONAR (SONAR_MESSAGE : in 
MESSAGE FORM) do 

IN TASK := SONAR_MESSAGE; 
end UPDATE_SONAR; 


delay SONAR_INT; 
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IN_TASK.ORIGIN 
IN_TASK.DESTIN 
INE TASK eH Rec iame 
IN_TASK.MESSAGE_CODE 


--INOUT. 


EMERG _MESSAGE.ORIGIN 
EMERG MESSAGE. DESTIN 
EMERG _MESSAGE.ENT CALL 


INOUT.SEND (EMERG MESSAGE) 


IN_TASK.ORIGIN 
IN _TASK.DESTIN 
INU TASK ENT CARL ees— 
INOUT.SEND (IN TASK); 

or 
terminate; 

end select; 

end loop; 


end SONAR; 
begin 
--reads the routing strategy 


CONPIG TO 7READ( InFromsaturn, 
FIRST _MESSAGE.MASK(VENUS) := 


SEND( IN TASK ); 


= TASK SONAR; 
TASK SCREEN; 
OUTPUT; 


Tes 
-- debugging message 


u 


TASK SONAR g 
TASK AVOIDANCE; 
:= OB AVOID ; 


f 


TASK SONAR ; 
TASK NAVIGATION; 
SONAR_OBSTICLE ; 


initialization message 
FIRST MESSAGE); 
TRUE; 


--passes the routing strategy message to MARS 
CONFIG IO.WRITE(OutToMars, FIRST_MESSAGE),; 


--reads the period interval initialization message 
PERIOD IO.READ({ InFromSaturn, SECOND MESSAGE 
SECOND MESSAGE.MASK(VENUS) := TRUE; 


--passes the period interval message to MARS 
PERIOD _ IO.WRITE(OUCTOMars, SECOND MESSAGE ay, 


--initialize the routing strategy table 
VENUS TABLE := VENUS _CONFIG(FIRST_MESSAGE.ROUT_ INFO); 


--initialization of task INOUT 

INOUT. INIT] (LOCATION); -- main node program ID 
INOUT. INIT2(OUT_ARRAY); -- output channel array 
INOUT.INIT3(VENUS TABLE); -—= routing erabie 


loop 
--Reads message from a input channel 
MESSAGE IO.READ (VENUS_ARRAY, VENUS_GUARD, 
WHICH CHANNEL, IN_MESSAGE); 
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~-increments VENUS counter in PROG(3) message field 
IN _MESSAGE.PROG(3) := IN_MESSAGE.PROG(3) + 1; 


--if a shutdown message has arrived exit the loop 
if IN_MESSAGE.ORIGIN = SHUTDOWN and IN MESSAGE.DESTIN = 
Hesterask then 


IN MESSAGE.PROG(3) := -1 * IN MESSAGE. PROG(3); 
INOUT. INCOMING (IN MESSAGE); 
exit; 

end if; 


--sends input message to the traffic handler(task INOUT) 
INOUT.INCOMING (IN_MESSAGE); 
end loop; 


end VENUS; 
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APPENDIX C: BASIC ADA PACKAGES USED IN TASK ALLOCATION 


A. DISET.ADA 


generic 
type ATOM is range <>; -- Must be a discrete type 


package DISCRETE SET is 


type SET 1S private; 
type ATOM_LIST is array (INTEGER range <>) of ATOM; 
Function CREATE return Ser; 
function UNION (A, BB: SET) "returns 
function INTERSECTION (A, B : SET) recurnesEr 
function DIFFERENCE (A, 8B: SET) return oem: 
function COPY (A; SET) return SET 
function BUILD SET (lL: ATOM LIST) retumie aa 
procedure INSERT (A: ATOM; S: in out SET); 
procedure DELETE (A: ATOM; Ss inoue scr). 
function MEMBER(A: ATOM; S: SET) return BOOLEAN; 
funetion SUBSET(A, B: SET) return BOOLEAN: 
function EQUAL(A,B: SET) return BOOLEAN; 
function 1S FULL(A: SET) return BOOLeAn,. 
procedure TAKE OUT MEMBER(A: in our Sel; 
OUT_ATOM: cue ATOM, 
SUCCESS: oul BOOLEAN: 
function COUNT MEMBERS(A: SET) return INTEGER; 
procedure CURAR SECS. imour chr), 


private 
type SET is array (ATOM’FIRST..ATOM’LAST) of BOOLEAN; 


end DISCRETE_SET; 


package body DISCRETE _SET is 


function T return BOOLEAN renames TRUE; 
function F return BOOLEAN renames FALSE; 


function CREATE return SET is 


begin 
return(others => F); 
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end CREATE; 


Toone UNTON (A,B + SET) return SET is 
begin 

PetbwEnmeA. OF eh; 
end UNION; 


mioct ren INTERSECTION (A,B: SET) return SET is 
begin 

return A and B; 
end INTERSECTION; 


Sinetron OIPERRENCE (A,B : SET) return SET is 
begin 

beturnm A and (A xor B); 
end DIFFERENCE; 


Gincirom COPY (A: SET) return SET is 
begin 

return A; 
end COPY; 


PiMiGeLOnesUlLD SET (lb: ATOM LIST) return SET is 


Son. := CREATE; 
begin 
for I in L’RANGE loop 
INSERT(L(I),S); 
Ciel Oop, 


Feturn Ss; 
ena SULLD SET; 


meececure INSERT (A: ATOM; S: in out SET) is 
begin 

S(A) := T; 
end INSERT; 
meocedure DELETE (A: ATOM; S: in out SET) is 
begin 

S(A) := F; 
end DELETE; 
function MEMBER (A: ATOM; S: SET) return BOOLEAN is 
begin 

Peers A); 
end MEMBER; 


Senction SUBSET (A,B : SET) return BOOLEAN is 


Leal 


begin 
return (A and 8) se, 
end SUBSET; 


function EQUAL (A,B: SET) return BOOLEAN was 
begin 

return A=B; 
end EQUAL; 


function IS FULL(A: SET) return BGOLEA ia. 


begin 
for I in A cance loop 
af AC ly =F chen 
jMeneelawall | lke 
end if; 
end leona; 
recur LD, 
end 18 FULL; 


procedure TAKE OUT_MEMBER(A: in out SET; 
OUT ATOM: out ATOM; 
SUCCESS: OU) BOOUHAN) tees 


begin 
SUCCHSo.:=.87 
for I an A range loos 
if ACh) = 2 hen 
OUT_ATOM := I; 
SUCCR Gs :— i: 
AGG) 2=sn- 
exit; 
else 
OUT ATOM == 1: 
end if; 
end loop; 
end TAKE OUT MEMBER; 


function COUNT MEMBERS(A: SET) return INTEGER is 
COUNT: INTEGER <= 0; 


begin 
for I in A‘range loop 
if A(I) = T then 
COUNDT.<= COUNT + i 
end if; 
endelaog, 
return COUNT, 
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end COUNT MEMBERS; 
procedure CLEAR_SET(S: in out SET) is 


SUCCESS: BOOLEAN := TRUE; 
A: ATOM; 


begin 
while SUCCESS loop 
TAKE OUT MENBER(S,A,SUCCESS); 
end loop; 
end CLEAR_SET; 


end DISCRETE SET; 


B. GRAPH2.ADA 


generic 


--Types to be instantiated 
type STANDARD _ ELEMENT is private; 
Eyoc Mew IYER. Vs private; 


--Function to be instantiated 
CaeimuinctvOns Yeq kl, K2?eKEY TYPE) return BOOLEAN; 


-- Procedures to be instantiated 
with procedure PROCESS(E: STANDARD ELEMENT; EKEY: 
KEY TYPE); 


package GRAPH2 ADT is 


--Elements: A graph consists of nodes and edges. Although, 
--in general each node may contain many elements, this 
-~-package defines that each node will contain exactly one 
~-~element of type STANDARD ELEMENT. Since an element 

--is assumed to have a unique key, each node is uniquely 
--identified by the key value of the element it contains. 
~-The key value has a type KEY TYPE. 


~-~Structure: An edge is a one-to-one relationship between 
~-a pair of distinct nodes. A pair of nodes can be 
--connected by at most one edge, but any node 

-~-can be connected to any collection of other nodes. 


--Domain: The number of elements in the graph is bounded. 


type DGRAPH is private; 
DGRAPH_ERROR: exception; 


--Operations: If G is a graph then reference to G-pre ina 
--postcondition is a reference to the value olsem ise 
==PricGr fomrhe Operation. 


procedure INSERT_NODE(G: in out DGRAPH; 

TKEY?: in KEY Seer 

E: in STANDARD ELEMENT; 

SUCCESS: out BOOLEAN) ; 
==pre =— None. 
--post - If G-pre is not full and does not contain an 
--element whose key value is e.key , then G contains e 
--and INSERT _ NODE is true, else INSERT NODE Vise: ayo 


procedure INSERT EDGE(G: in out) DGRAPH, 
FROM_KEY, TO KEY: in KEY_TYPE; 
W: in STANDARD ELEMENT; 
SUCCESS: out BOOLEAN); 


==pre = None. 

--post - If KEY1 /= KEY2, and G-pre is not full, 
--contains nodes nl and n2 with elements whose key 
--values are KEY1 and KEY2, and does not contain an edge 
--connecting those nodes, then G contains an edge ~ 
==-connecting nl and n2 and INSERT EDGE 1s trueyecms— 
--INSERT_NODE is false. 


procedure RETRIEVE EDGE(G: in out DGRAPH; 
FROM KEY, TO KEY: in KEY_TYPE; 
W: out STANDARD_ELEMENT; 
SUCCESS: out BOGEEAM 


—-pre — Neve. 

--post - Returns the weight and success = true if the 
--edge exists if the edge does not exist returns 
--success = false. 


procedure DELETE _NODE(G: in out DGRAPH; 
TREY: in KEvet vee 
SUCCESS: out BOOLEAN: 


—-Dpre — Nene. 

--post - If G-pre contains node nl, whose element has key 
--value KEY1, then G does not contain nl or any of the 
--edges that connected nl to other nodes in G-pre, and 
--DELETE NODE is true, else DELETE_NODE is false. 
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procedure DELETE_EDGE(G: in out DGRAPH; 
TAPROMpeEhtO, sin KEY TYPE: 
SUCCESS: out BOOLEAN); 


--pre - None. 

Sasosum— lhe G-pne COneainc am sedge connecting nodes whose 
--elements have key values KEY1 and KEY2 then G does not 
--contain that edge and DELETE EDGE is true, else 
--DELETE EDGE is false. 


procedure UPDATE _NODE(G: in out DGRAPH; 
Pei. an KE YetyYPr, 
E: in STANDARD ELEMENT; 
SUCCESS: out BOOLEAN); 


Ole = NONE. 

--post - If G-pre contains element e-pre with key value 
--e.KEY1 then G contains e, but not e-pre, and Update is 
--true, else Update is false. 


procedure UPDATE _EDGE(G: in out DGRAPH; 
FROMKBEY, TOKEY: in KEY TYPE; 
W: in STANDARD _ELEMENT; 
SUCCESS; Out BOOLEAN); 


Procedure RETRIEVE NODE(G: in out DGRAPH; 
TREY? inher YPE: 
E: out STANDARD ELEMENT; 
SUCCESS: oUt BOOLEAN); 


abe — NOTE. 

--post - If G-pre contains element E-pre with key value 
--KEY1, then E is E-pre and RETRIEVE returns true, else 
--RETRIEVE is false. 


procedure CREATE(G: in out DGRAPH; 
SUCCHSs: cut BOOLEAN); 


ao eee— None. 

--post - If a graph can be created than G is an empty 
--graph and CREATE is true, else CREATE is false. 
Euccedure KILL(G: in out DGRAPH); 


=-pre — None. 
--post - GRAPH G does not exist. 


procedure SET WAITING(G: DGRAPH); 


--pre - graph must be fully connected 
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procedure BREADTH FIRST _SEARCH(G: DGRAPH); 


procedure DEPTH FERS? SBARCH(e. ShGRAGH 


private 


type STATUS is (WAITING, READY, PROGESSED Ey 
type GRAPH_NODE; 

type NODE_PTR is access GRAPH_NODE; 

type EDGE NODE; 

type EDGE PTR is access EDGE NODE; 


type GRAPH NODE is 

record 
ELT: STANDARD ELEMENT; 
NODESKEY: KEY 2TYPE. 
NEXT NODE: NODE PTR; 
EDGE_HEAD: EDGE PTR; 
NODE _STATUS : Slates: 

end record; 


type EDGE_NODE is 
record 
DESTIN KEY: KEY_TYPE; 
NEXT_EDGE: EDGE PTR; 
WEIGHT: STANDARD ELEMENT; 
EDGE_STATUS: STATUS; 
end record; 


type DGRAPH TYPE is 


record 
HEAD, TAIL: NODE PTR; 
SENTINEL : NODE_PTR; 


end record; 


type DGRAPH is access DGRAPH_ TYPE; 
end GRAPH2_ ADT; 
with UNCHECKED DEALLOCATION; 
with QUEUES2; 


package body GRAPH2_ ADT is 


package MY_QUEUE is néw QURUES2(NODEEPIR); 
use MY OUERUE; 


136 


eeecceulpe FINO NODE (G.eumout DBGRAPH; TKEY: in KEY TYPE; 
PTR: out NODE PTR) is 


Ce] NODE LPTR; 


begin 
fe Gene AD 7— null then 
G.SENTINEL.NODE KEY := TKEY; 
CerAtli. NEXT NODE := (G7SENTINEL; 
Gem GeHEAD- 
while TKEY /= GP.NODE_ KEY loop 
GP := GP.NEXT NODE; 
if GP = null then 
PTR := GP; 
Ge turn; 
ena .f- 
enc loop, 
Celebi Neat NODE e;— null; 
if GP /= G.SENTINEL then 
PTR := GP; 
Tee blie ww 
enge1t? 
end if; 
PTR := null; 


end FIND NODE; 


procedure INSERT_NODE(G: in out DGRAPH; 
PRE cee ee Ye i 
E: in STANDARD ELEMENT; 
SUCCESS: Out BOOLEAN) is 


GP; NODE PTR; 
AUX: NODE PTR; 
OK: BOOLEAN; 


procedure CREATE NODE(P: in out NODE_PTR; 
TKEY: in KEY TYPE; 
E: in STANDARD ELEMENT; 
SUCCESS: out BOOLEAN) is 


begin 
P ;= new GRAPH NODE; 
SUGERSS “= TRUE; 
Sets 1; 
P.NODE KEY := TKEY; 
excepelon 
when STORAGE ERROR => 
SsUCCESs =:= FALSE; 


end CREATE NODE; 


begin 
FIND NODE(G, TKEY, AUX); 
if AUX = null then 
CREATE NODE(GP, TKEY, E, OK); 


if OKVenen 
if G.HEAD = null then 
G.HEAD := GP; 
else 
G.TAIL.NEXT NODE := GP; 
end if; 
G.TAIL := GP; 
SUCCESS <= TRUE; 
end if; 
else 
SUCCESS += FALSE; 
end aa * 


end INSERT_NODE; 


procedure FIND EDGE(G: in out DGRAPH; 
TRFROM, TKEO? in KEY Seer 
EP. OUL) EDGEEE IR, 
SUCCESS: out BOOLEAN) is 


AUX_EDGE_PTR: EDGE PTR; 
AUX_NODE_ PTR: NODE PTR; 


begin 
SUCCESS := FALSE; 
FIND _NODE(G, TKFROM, AUX NODE PTR); 
if AUX_NODE_PTR =null then 


SUCCESS := FALSE? 
else 
if AUX_NODE_PTR.EDGE HEAD /= null then 
AUX_EDGE PTR := AUX _NODE_PTR.EDGE HEAD; 


while AUX_EDGE PTR /= null loop 
if AUX_EDGE PTR.DESTIN KEY = TKTO then 
SUCCESS.) = TRUE 
EP := AUX_EDGE PTR; 
exit; 
end if; 
AUX_EDGE_PTR := AUX EDGE PTR.NEXT_ EDGE; 
end loop; 
else 
SUCCESS ?= FALSE: 
end if; 
end if; 
end FIND EDGE; 


procedure INSERT_EDGE(G: in out DGRAPH; 


FROM_KEY, TO_KEY: in KEY_TYPE; 
W: in STANDARD ELEMENT; 
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SUCCESS: out BOOLEAN) is 


ALREADY_EXISTS: BOOLEAN; 

AUX NODE PTR: NODE_PTR; 

AUxEDGE PTR, AUX EDGE PTR2Z: EDGE PTR; 
Ok wr PIR, 


begin 
HIND OE DGE(G, FROM KRY, TO_KEY, EP, ALREADY EXISTS); 
if ALREADY EXISTS then 


SuCCi Ss += FALSE; 

else 
EP :;= new EDGE NODE; 
Pero Vin hE Yo = TOKE, ; 
EP.WEIGHT := W; 
EP.NEXT EDGE := null; 


FIND NODE(G, FROM_KEY, AUX NODE PTR); 


if AUX NODE PTR.EDGE HEAD = null then 
AUX NODE PTR.EDGE HEAD := EP; 
else 
AUX_EDGE_PTR1 := AUX_NODE_PTR.EDGE_ HEAD; 
while AUX_EDGE_PTR1 /= null loop 
AUX EDGE _PTR2 := AUX_EDGE_PTR1; 
AUX_EDGE PTR1 := AUX_EDGE PTR1.NEXT_EDGE; 
end loop; 
AUX_EDGE PTR2.NEXT_ EDGE := EP; 
end if; 
end it 


end INSERT_EDGE; 


procedure RETRIEVE EDGE(G: in out DGRAPH; 
FROM KEY, TO KEY: in KEY_TYPE; 
W: out STANDARD ELEMENT; 
SUCCESS: out BOOLEAN) is 


HP EDGE SPRITR, 
OK: BOOLEAN; 


begin 
FIND EDGE(G, FROM KEY, TO KEY, EP, OK); 
if OK then 
SUCCESS := TRUE; 
W := EP.WEIGHT; 
else 
SUCCESS := FALSE? 
end i1t- 


end RETRIEVE _EDGE; 
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procedure FREE _GRAPH_NODE is new 
UNCHECKED _ DEALLOCATION (GRAPH NODE,NODE PTR); 


procedure DELETE NODE(G: in out DGRAPH; 
TKEY: in KEY TYPu, 
SUCCESS: out BOOLEAN was 


AUX NODE PUR) NODES; 
EP: EDGESE IE 

OK: BOOLEAN; 

GP: NODEL PUR; 

PREVIOUS: NODE PIR; 
Pik: NOPEOPTR; 


begin 
if G.HEAD = null then 
SUCCESS. 2= PAUSE, 
else 
--first delete all edges towards this node 
AUX_NODE_ PTR := G.HEAD; 


if AUX_NODE_PTR.NODE_KEY /= TKEY then 
DELETE _EDGE(G, AUX NODE PTR.NODE_KEY, TKEY, OK); 


end if; 
while AUX_NODE_PTR.NEXT_NODE /= null loop 
AUX NODE PTR := AUX_NODE PTR.NEXAT NORE, 


if AU NODE UPI Re NODE RE /= TKEY then 
DELETE UEDGEce, AUX_ _NODE_PTR.NODE KEY, TREY, 30 


end if; 
end loop; 
--delete the node 
G SENTINEL. NODE KEY c— ThE, 
G.TAIL.NEXT NODE := G.SENTINEL; 
GP := G.HEAD; 
PREVIOUS := GP; 
while TKEY /= GP.NODE KEY loop 
PREVIOUS := GP; 
GP := GP.NEXT_NODE; 
end loop; 
G.TAIL.NEXT_NODE := null; 
if GP /= G.SENTINEL then 
Pike: = GP; 
if PTR = PREVIOUS then 
G, HEAD := PIR. NEXT NODE 
FREE GRAPH NODE(PTR); 
else 
PREVIOUS .NEXT NODE :- PTR: NEAT NODE, 
PTR.»NEXT NODE == snl; 
FREE GRAPH NODE(PTR); 
end if> 
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SWECCESS, s—— LRU 
else 
SUCCESS := FALSE; 
end if; 
end if; 
end DELETE NODE; 


procedure FREE EDGE NODE is new 
UNCHECKED _ DEALLOCATION (EDGE NODE, EDGE PTR); 


procedure DELETE_EDGE(G: in out DGRAPH; 
TREROM, TKTO: an KEY TYPE; 
SUCCESS: out BOOLEAN) is 


AUX _NODE_PTR: NODE PTR; 
BUSSE OGRE PER. EDGE PIR; 
BP.) BOCES PTR: 

PREVEOUS: EDGE PTR; 

OK: BOOLEAN; 


begin 
OK := FALSE; 
FIND NODE(G, TKFROM, AUX _NODE PTR); 
if AUX_NODE PTR = null then 


OK := FALSE; 

else 
AUX_EDGE PTR := AUX_NODE_PTR.EDGE_HEAD; 
PREVIOUS := AUX_EDGE PTR; 


while AUX _EDGE _PTR /= agouil loop 
if AUX_ EDGE eudel DESTIN KEY = TKTO: chen 


OK := TRUE; 
EP := AUX EDGE PTR; 
exit; 
ene Grits 
PREVIOUS := AUX_EDGE_PTR; 
AUX_EDGE PTR := AUX_EDGE PTR.NEXT EDGE; 
end loop; 
if OK then 
if PREVIOUS = AUX EDGE _PTR then 
AUX NODE PTR.EDGE_HEAD := AUX_EDGE_PTR.NEXT_EDGE; 
FREE EDGE NODE(AUX_EDGE_PTR); 
else 
PREVIOUS.NEXT_EDGE := AUX_EDGE PTR.NEXT_EDGE; 
AUX_EDGE PTR. NEXT_ EDGE := null; 
FREE _EDGE _NODE(AUX_ EUGE PIR): 
end see 
endirt - 
end if; 
SUCCESS := OK; 


eac DE LEER EDGE; 
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procedure UPDATE _NODE(G: in out DGRAPH; 
TREY :) dees Ye ee ae 
E: in STANDARD ELEMENT; 
SUCCESS: out BOOLEAN) is 


PTR: NODEDPTR, 
begin 


FIND _NODE(G, TREY pee. 
if PTR = null then 


SUCCESS := FALSE; 
else 

PPR Bie a= Er 

SUCCESS := TRUE; 
end at; 


end UPDATE NODE; 


procedure UPDATE _EDGE(G: in out DGRAPH; 
FROMKEY, TOKEY: in KEY TYPE; 
W: in STANDARD ELEMENT; 
SUCCESS: out BOOLEAN jis 


EP: EDGE PTR; 
OK: BOOLEAN; 


begin 
FIND EDGE(G, FROMKEY, TOKEY, EP, OK); 
if OK then 
EP.WEIGHT := W; 
SUCCESS += TRUE; 
else 
SUCCESS := FALSE; 
ena if: 


end UPDATE _EDGE; 


procedure RETRIEVE NODE(G: in out DGRAPH; 
TREY. see eee 
E: out STANDARD ELEMENT; 
SUCCESS: out BOOLEAN) is 


PTR: NODE PPR; 
begin 


FIND NODE(G, TREY) etki 
if PTR = null then 


SUCCESS := FALSE? 
else 

E := PTR.ELT: 

SUCCESS := TRUE; 
end sat, 
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end RETRIEVE _NODE; 


procedure CREATE(G: in out DGRAPH; 
SUCCESS: out BOOLEAN) is 


begin 
G := new DGRAPH_TYPE; 
G.SENTINEL := new GRAPH NODE; 
SUCCESS := TRUE; 
exception 
when STORAGE ERROR => 
SUCCESS := FALSE; 


end CREATE; 
procedure KILL(G: in out DGRAPH) is 
BL: BOOLEAN; 
begin 
while G.HEAD /= null loop 
DELETE NODE(G, G.HEAD.NODE KEY, BL); 
ena loop; 
end KILL; 


procedure SET _WAITING(G: DGRAPH) is 


AUX_NODE_ PTR: NODE PTR := G.HEAD; 
AUX_EDGE_PTR: EDGE PTR; 
begin 
while AUX_NODE_ PTR /= null loop 
AUX_NODE_PTR.NODE_ STATUS := WAITING; 


AUX_EDGE_ PTR := AUX_NODE_PTR.EDGE_HEAD; 
while AUX_EDGE PTR /= null loop 


AUX_EDGE PTR.EDGE STATUS := WAITING; 
AUX_EDGE PTR := AUX EDGE PTR.NEXT_EDGE; 
end loop; 
AUX_NODE_PTR := AUX_NODE_PTR.NEXT_ NODE; 
end loop; 


end SET_WAITING; 
procedure BREADTH FIRST SEARCH(G: DGRAPH) is 
oO. QUEUE > 


SUCCESS: BOOLEAN; 
GP: NODE_PTR; 


AUX_GRAPH: DGRAPH := G; 
procedure VISIT(P: in out NODE_PTR) is -- Visit a graph 
--node 


143 


EP: EDGE PTR; 
AUX_NODE_PTR: NODE PTR; 


begin 
ENQUEUE(Q, P); 
while not EMPTY(Q) loop 
SERVE(Q, P); 
PROCESS (PVELI, 2. NOpER Kee, 
P.NODE STATUS := PROCESSED; 
EP := P.EDGE HEAD; 
while EP /= null loop -- Consider all neighbors 
FIND _NODE(AUX_GRAPH, EP.DESTIN_KEY, AUX_NODE_ PTR); 
if AUX_NODE_PTR.NODE_ STATUS = WAITING then 
ENQUEUE(Q, AUX_NODE_PTR); 


AUX NODE PTR.NODE STATUS := READY; 
end ai- 
BP t= BP.NEAT EDGE; 
end loop; 
end loop; 
end VISIT; 


begin 
CREATE (0; SUCCESS )_ 
if not SUCCESS then 
raise QUEUE ERROR; 
end if; 
SET WATTING(G); 
GP := G.HEAD; 
while GP /= null loop 
if GP.NODE_ STATUS = WAITING then 


VISIT(GP y= 
else 
GP := GP.NEXT NODE; 
end if: 
end loop; 


end BREADTH_FIRST_SEARCH; 


procedure DEPTH_FIRST_SEARCH(G: DGRAPH) is 
CE: NODESPIER, 
procedure VISIT(MY_P: NODE_PTR) is 
Ps NODESPTR  »-= MYlFP, 
BE. EDGE LPL: 
AUX NODE PTR: NODE PTR; 
AUX GRAPH: DGRAPA=:— G; 
begin 
PROCESS(P, ELT, P. NOUR ae ae), 
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P.NODE STATUS := PROCESSED; 
Eo — P.SSCEeHEar, 
while EP /= null loop 
FIND NODE(AUX_GRAPH, EP.DESTIN_KEY, AUX_NODE_PTR); 


if AUX_NODE_PTR.NODE STATUS = WAITING then 
Visti AUARNODEMP TR ); 
end if; 
Pe oe Neer; 
end loop; 
endo Vis lis 


begin 
SET WALTTING(G); 
GP := G.HEAD; 
while GP /= null loop 
if GP.NODE STATUS = WAITING then 


ViSTU(GP). 
else 
GP :— GP.NEAD NODE; 
end if; 
end loop; 


SiGe EP Tier I RSE SEARCH, 
end GRAPH2_ ADT; 
C. QUEUES2.ADA 


memeric 
type STANDARD ELEMENT is private; 


package QUEUES2 is 
--Elements: Although the elements can be a variety of 
--types, for concreteness we assume that they are of type 
--standard element. 
--Structure: The structure is a mechanism for relating the 
--elements that allows determination of their order of 


--arrival into the queue. 


--Domain : The number of elements in the queue is 
~-bounded. 


type QUEUE is private; 
SUERUESERROR: exception; 


--Operations: There are six operations. Occasionally in 
--the postcondition we must reference the value of the 
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--queue immediately before execution of the operation. We 
--use Q-pre as notation for this operation. 


procedure ENQUEUE(Q: in out QUEUE; E: in 
STANDARD_ELEMENT) ; 


--pre: The size of Q is less than its bound. 
--post: Q includes E as its most recently arrived element. 


procedure SERVE(Q: in out QUEUE; E: out STANDARD ELEMENGy 
--pre: Q is not empty. 

--post: E is at least recently arrived element of Q-pre; 
--Q does not contain E. 

function LENGTH(Q: in QUEUE) return NATURAL; 

--post: Length is the number of elements in Q. 

function FULL(Q: in QUEUE) return Boorman. 

--post: If the size of Q is less than its bound then Full 
--is false, ; 

--else full is true. 


function EMPTY(Q; in QUEUE) return BOOLEAN: 


--post: If the size of Q is zero returns TRUE else returns 
--FALSE. 


procedure CREATE(Q: in out QUEUE; SUCCESS: out BOOLEAN: 
--post: If a queue can be created, then q exists and is 
--empty and create is true, else create is false. 
procedure KILL(Q: in out QUEUE); 
--post: Q-pre does not exist. 

private 
type NODE; 
type NODE POINTER is access NODE; 


type NODE is 


record 
ELEMENT: STANDARD ELEMENT; 
NEXT ; NODE UPGINTER: 


end record; 


type QUEUE_INSTANCE is 
record 
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HEAD, 
Pali NODE POINTER, 
SiZE: NATURAL 2= 07; 
end record; 
type QUEUE is access QUEUE_INSTANCE; 


end QUEUES2; 


with UNCHECKED DEALLOCATION; 
package body QUEUES2 is 
procedure ENQUEUE(Q: in out QUEUE; E: in STANDARD ELEMENT) 


is 
--Add element E to queue Q. 


begin 
if Q.SIZE = 0 then --insert new node into empty queue 
Q.TAIL := new NODE’(E, NULL); 
O°] XUEBAD Y= ©. TAIL; 
else 
Q.TAIL.NEXT := new NODE’(E, NULL); --link new node to 
--tail 
O.TAIG := ©.TAIL.NEXT; 
ena if; 
Q.SIZE := QO.SIZE + 1; 
exception 


when STORAGE ERROR => 
raise QUEUE_ERROR; 
end ENQUEUE; 


procedure DISPOSE is new UNCHECKED DEALLOCATION(NODE, 
NODE POINTER) ; 


procedure SERVE(Q: in out QUEUE; E: out STANDARD ELEMENT) 


is 
--Retrieve and remove most recently added element. 
P: NODE POINTER; --temporary pointer 


begin 
if Q.SIZE = 0 then --queue is empty 
raise QUEUE_ERROR; 
end if; 


E Q.HEAD.ELEMENT; --extract top element 
P := Q.HEAD; 
Q.HEAD := Q.HEAD.NEXT; 
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DISPOSE(P); 
O,SLZR 3] JOesicn ol. 
end SERVE; 


function LENGTH(Q: in QUEUE) return NATURAL is 


--return size of the queue 
begin 

Preecurn wes iake 
end LENGTH; 


function FULL(Q: in QUEUE) return BOOLEAN is 


--Is Q full? 

P: NODE POINTER; --temporary pointer 
begin 

P := new NODE; 

DISPOSE(P); 

return FALSE; 
exception 

when STORAGE ERROR => 

Trecurue TRUE 

end PULL; 


function EMPTY(Q: in QUEUE) return BOOLEAN is 


--Is Q empty 
begin 

return 9.SIZE = 0; 
end EMPTY; 


procedure CREATE(Q: in out QUEUE; SUCCESS: out BOOLEAN) is 


--I£f a queue can be created, then do so and return 
--SUCCESS = true else return SUCCESS = FALSE. 
begin 

if Q = NULL then 


Q := new QUEUE_INSTANCE; 
SUCCESS +=) TRUE; 
else --storage has already been allocated for queue 
KILL(Q); 
end if; 
exception 
when STORAGE ERROR => -- out of memory 
SUCCESS <2—= FRESE; 
end CREATE; 


mreeccduge KIGL(O: in eur OUERUE) is 


Ps NODE POINTER; 


begin 
while Q.HEAD /= NULL loop 
Pee— eo HEAD: 
Q.HEAD := Q.HEAD.NEXT; 
DESPOSE CP ); 
end loop; 
Cee = NU 
Q.SIZE := Q; 
end KILL; 


end QUEUES2; 


D. SORT.ADA 


generic 

type STANDARD _ ELEMENT is private; 

type INDEX is range <>; 

Tee cuncrtGhewG (Khil,k2: STANDARD ELEMENT) return 
BOOLEAN; 


package SORT_ADT is 
--Each of the procedures in this module, except heapsort, 
--sorts an array of standard elements into ascending 


--order.Heapsort sorts into descending order. 


type SORT_ARRAY is array (INDEX range <>) of 
STANDARD ELEMENT; 


meocedure SKEECT SORT (R: in out SORT ARRAY); 
peocedure EXCHANGE SORT(R: in out SORT ARRAY); 
peecedure INSERT SORT (R: in out SORT ARRAY); 
pmececure Os 2° (R: in out SORT ARRAY); 
peoceduce Os 3 (R: in Out SORT ARRAY); 
procedure MERGE SORT (R: in out SORT_ARRAY); 


end SORT ADT; 


package body SORT_ADT is 
procedure SWAP (EL1, EL2: in out STANDARD_ELEMENT) is 


TEMP_EL2: STANDARD ELEMENT := EL2; 


149 


begin 


Ele =) Ede 
ELD .= TREMP sho 
end SWAP; 


function ">" (El, E2: STANDARD ELEMENT) return BOOLEAN Mi. 
begin 

return (Hl /= EZ) and not (eis ane 
end 1 > “ . 
function ">=" (E1,E2: STANDARD ELEMENT) return BOOLRANMEE. 
begin 

return (Bl > EZ) er {Hl = 2), 
end iL >="5 
function "<=" (El, E2: STANDARD ELEMENT) return BOOLEAN is 
begin 

return {Hl < F2) Or (bl — Boe 
end "<=s"s 


procedure SELECT SORT (R: in out SORT ARRAY 


SMALL: INDEX; 


begin 
for K in R‘'FIRST.. INDEX’ PRED(R LAST wlogp 
SMALL := K; 


for J ian INDEX’ SUCC(K). KR LAST ‘oon 
if RCI) < RUSMALL) tien 


SMALL := J; 
end if; 
end loop; 
SWAP (R(K), R(SMALL)); 
end loop; 


ena SELECT SORT; 
procedure EXCHANGE SORT (R: in out SORT_ARRAY) is 


SORTED: BOOLEAN; 


Ke INDEX; 
begin 

K i= R’ LAST; 

SORTED -— FALSE? 


while (K > R’FIRST) and (not SORTED Mice 
SORTED := TRUE; 


0 


for J in R’FIRST..INDEX’PRED(K) loop 
Tal ReINDE< SUGC (a) Ehen 


SORTED := FALSE; 
end if; 
end loop; 
K := INDEX’PRED(K); 
end loop; 


end EXCHANGE SORT; 
procedure INSERT_SORT (R: in out SORT_ARRAY) is 


SAVE: STANDARD ELEMENT; 
J. INDEX; 


begin 
ie meNG TH > le hen 
TOR wiiehevercCun HIRST ti ExX PRED(R LAST) loop 
Js =" INDEX” SUCC(K); 
SAVE $= R(K); 
while (SAVE > R(J)) loop 
R(INDEX’PRED(J)) := R(d); 
foo <ek LAST then 
Je =I NEA SUCC (ld); 
else 
exit; 
end it: 
end loop; 
if SAVE > R(J) then 
R(J) := SAVE; 
else 
R( INDEX’PRED(J)) := SAVE; 
end if; 
end loop; 
end if; 
end INSERT SORT; 


Peeceaure Os 2 (R: in out SORT ARRAY) is 
procedure QUICK _2(LEFT, RIGHT: INDEX) is 
--post - Element R(LEFT)-pre is in the sorted 
--position, say k, with R(LEFT) ... R(K-1) less then 
aor yeeanad Ri Kl)... R(RIGHT) larger than R(K). 


wk. INDEX; 


begin 
it GEE) <eRIGHT then 
Oe = bE PTs 
Koo = RIGHT: 


if R(LEFT) > R(RIGHT) then 


sya 


SWAP(R(LEFT), R(RIGHT)); 
end ie: 
leéeo) -——unt i le 
loop =-until R(d) >= RG@EEER 


J°s= INDEX “SUCC( a 

exit when R(J) >= R(LEFT); 
end lees, 
loop --until R(K) <= R(LEFT) 

K i= INDEX PRED(K); 

exit when R(K) <= R(LEFT); 
end loop; 


if J < K then 
SWAR( ER(d)y RK), 
end if; 
exit when J > K; 
end loop; 
SWAP(R(LEFT), R(K)); 
if K > INDEX FIRS? then 
QUICK 2 (LEFT, INDEX’PRED(K)); 
end af; 
QUICK _2 (INDEX’SUCC(K), RIGHT); 
end if; 
end QUICK 2y 


begin --QS_2 
QUICK 2(h FIRST, BR” EAST); 
ences. 2; 


procedure QS 3 (R: in out SORT_ARRAY) is =-Ouveksoue 
procedure QUICK3(LEPT, RIGHT: INDEX) as 


J, KR. + INDEX; 
begin 
if LEFT < RIGHT then 
--Median of 3 modification 
SWAP(R( INDEX’VAL((R‘LENGTH+1)/2)), 
R( INDEX’ SUCC(LERT) )): 
if R(INDEX’SUCC(LEFT)) > R(RIGHT) then 
SWAP(R( INDEX’ SUCC(LEFT)), R(RIGHT)); 
end if; 
if R(LEFT) > R(RIGHT) then 
SWAP(R(LEFT), R(RIGHT)); 
end if; 
if R(INDEX'SUCC(LEFT)) > R(LEFT) then 
SWAP (R( INDEX’ SUCC(LEFT)), R(LEFT)); 
end if; 


--After Median of 3 mod. is complete, the Jsnallece 
-~-sample value will be in position LEFT + 1; the 
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--largest sample value will be in position RIGHT; 
--and the median sample value will be in 
-~position LEFT. 


Ue — ON DEX SUGE(LERT), 
K := RIGHT; 
loop 


loop --Advance J right until a value greater than 
--R(LEFT) is found 


J =  ENDEX, SUCE (J); 
exit when R(J) >= R(LEFT); 
end loop; 


loop --Advance K left until a value less than 
--R(LEFT) is found. 


K := INDEX’ PRED(K); 
exit when R(K) <= R(LEFT); 
eucde Loop, 
if J < K then -- Swap values 
SWAP(R(J), R(K)); 
end if; 
exit when J > K; 
end loop; 
SWAP (R(LEFT), R(K)); --Put median value into its 


--sorted position 


--QUICK SORT remaining sublist partitions if they 
--contain 10 or more elements. 


if (INDEX’POS(K) - INDEX’POS(LEFT)) > 10 then 
QUICK3(LEFT, INDEX’PRED(K)); 
end if; 
if (INDEX’POS(RIGHT) - INDEX’POS(K)) > 10 then 
OUICK3S{ INDEX’ SUCC(K), RIGHT); 
end) 47; 
end err ¢ 
end QUICK3; 


begin --QS 3 
QUICK3 (R’FIRST, R‘LAST); 
INSERT_SORT(R); 
eee OS 3; 
procedure MERGE(L: NATURAL; R,T: in out SORT_ARRAY) is 


--pre - Array R contains sorted sublists of length L. 
--post- Array T contains sorted sublists of lenght 2L. 


Q, Kl, K2, END1, END2: NATURAL; 


begin 


a2 


if L >= R’LENGTH then 
T SR 
Erebuinm, 
end if; 
Kl := 1; -- Kl and K2 are indexes for the sublists to 
KZ = b&b fl oe enged 
Oe Oy, 
loop -- Repeat 
END! j=] Kl} ba 
if END1 > R’LENGTH then --Mark the ends of the 
-~-sublists to be 
END1 R‘' LENGTH; --merged. 
else 
END2 = — K25-) bowie 
if END2 > R’LENGTH then 
END2 := R’LENGTH; 
end if; 
while (Kl <= END1) and) (K2 <= END2)\eiloop 
if R( INDEX’ VAL(K1)) <= RCINDEX* VAL CR? eee 


T(INDEX’VAL(QO+1)) != R(UINDEX Vane: 
Kies] Kies ae 
else 
T( INDEX’ VAL(Q+1)) := R( INDEX’VAL(K2)); 
K2 = K2° 
end if; 
Of. - 0, 
end loop; 
end at: 
if Kl <= END1 then -~-Tack on elements from the 


-~-sublist with 
for K in Kl..END1 loop --more elements 
T( INDEX’ VAL(Ot1)) *= RCINDEX Val nape 
O.-e= Or ly 
end loop; 
Kl 3s= ENDL + 1: 
else 
for K in K2..END2 loop 
T( INDEX’VAL(Q+1)) := R(INDEX’VAL(K)); 
Q := Ql; 
K2 := END2 + 1; 
end loop; 
KZ 3=SEND2Z + 1-> 
end sat; 
Ki sS—kK2" -~Set indexes for the next 
--pair of sublists 
KZ] ie ee 
exit when Kl > R’LENGTH; 
end lege, 


end MERGE; 
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procedure MERGE SORT (R: in out SORT_ARRAY) is 


ite oORT ARRAY(R’ FIRST. .R° LAST); 
L: NATURAL; 


begin 
lege =o 
if R’LENGTH >= 2 then 
loop 
MERCH (lL, R; T); 
es =z * ly 
MERGE(L, T, R); 
ies] 2*b; 
exit when L >= (R’LENGTH+1)/2; 
end loop; 
end if; 


if L < R’LENGTH then -- If necessary, a final merge. 


MERGE(L, R, T); 
Reo Sie 
end if; 
end MERGE_SORT; 


end SORT ADT; 


APPENDIX D: TASK ALLOCATION ADA PROCEDURES 


A. STATICAL.ADA 


with RANDOM; 

with TEXT 10; 

vee TEXTE SO; 

with QUEUES2; -- linked list implementation of queues 
with DISCRETE SET; -- sets are used as the main data 
== structures to control the’ alloestien 

with SORT_ADT; -- several schemes of sorting 

with GRAPH2_ ADT; -- adjacency list implementation of 
--directed acyclic graphs 


procedure STATICAL is 


-- instantation of I/O routines 

package INTEGER_INOUT is new INTEGER_IO( INTEGER); 
use INTEGER INOCUT; 

package FLOAT INOUT is new FLOAT I0( FLOAT); 

use FLOAT INOUT; 


-- defines the maximum number of tasks to be used with this 


-- program 
MAX PROCE Ss: constant INTEGER. — 925, 
NUM_OF_TASKS: INTEGER; -- global variable that holds the 


-- number of tasks in a task flow graph 


MAX INDEX: INTEGER; -- global variable that holds the 

-- maximum valid index for the heuristic aueay 

-- defines the maximum number of components that can be used 
-- by the array that holds the values calculated by 

-- heuristic for each possible graph edge 

MAX ARRAY: constant INTEGER := 

(MAX _PROCESS* (MAX PROCESS-1))/2; 


-- MY_ATOM is basically the task identifier 
type MY_ATOM is range 1..MAX PROCESS; 
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package MY_DIS is new DISCRETE_SET(MY_ATOM); 
use MY DIS; 


-- data structures used for the calculation of ancestor and 
-- parent arrays 

fjyoe PRED ARRAY is array (2..MY_ATOM’LAST) of SET; 
PARENT_ARRAY: PRED_ARRAY := (others => My DiSs GREATE }; 
ANCESTOR_ARRAY: PRED ARRAY := (others => MY DIS. CREATE ); 


-- record that defines the structure of the information 
-- stored on each task node and on each task edge 
type MY_ELEMENT is 


ieSeenee 
INFO: FLOAT; -- may represent execution costs(node) or 
-- communication costs(edge) 
ACCUMULATOR: FLOAT := 0.0; -- accumulator used for the 


-- calculation of the longest path cost and also by 
-- heuristics that take into account the displacement in 
-- time from the root task 
PROGESSmoE LT NSsET; —- Stores information related with the 
-- longest path ,that is the set of task identifiers 

-- that compose the longest path end record; 


-- record that defines the structure of the information 
-- stored in the 
-- array that holds the results of heuristic functions 


-- applications 
type MY_RECORD is 

record 
PAIR_SET: SET := MY_DIS.CREATE; -- edge defined as a 
-- pairset of task identifiers 
DiDAseF ROM; UNTEGER, —-—- Source nede 
INDEX_TO: INTEGER; -- destination node 
EFROM * FLOAT: -- execution time of the source 
-- node 
ETO LOA: -- execution time of the 
-- destination node 
COMM ; FLOAT; -- communications cost 
HINFO * FLOAT: -- result of the heuristic 
-- function 


end record; 
-- defines the number of processors used in the allocation 
a scheme 
mye PROCESSOR is (P1, P2, P3, P4, P5, P6, P7, P8, P9, 
EO); 


-- gets the number of processors to be used 
LAST_PROCESSOR: PROCESSOR; 


-- Array type that has one set per processor. Each set 


sey) 


-- defines which tasks are alle@eatéd £O Phateproce-ces 
type PROCESSOR_ARRAY is array(PROCESSOR) of SET; 


-- processor array for application of heuristic 
P_ARRAY: PROCESSOR_ARRAY := (others => MY_DIS.CREATE); 


-- Keeps track of the accumulated absolute utilization of 
-- each processor 

-- that composes the network 

type UTILIZATION ARRAY is array(PROCESSOR) of FLOAT; 


-- utilization array for applycation of heuristic? 
U_ARRAY: UTILIZATION ARRAY j= (others => OFOnr 


-- controls what are the tasks already allocated in 
-- accordance with heuristicl 


ALLOCATED TASKS: SET := MY_DIS.CREATE; 

UNI_EXE COST: FLOAT := 0.0; -- uniprocessor execution time 
-- of the data flow 

AUX_COST: FLOAT := 0.0; -- aux. variable to compute 

-- uniprocessor execution time 

AUX_COUNT: INTEGER := 0; -- global variable used by the 

-- procedure printout to count the number of tasks aia 

-- graph 

POTENTIAL SPEED _ UP: FLOAT; -- speed-up that could be 


-- achieved if the minimum cost were equal to the sum of 
-- the tasks that compose the longest path 


-- Record used by the procedure SCHEDULE 
type EXECUTION_INFO is 


record 
START TIME: PLOAT: -- task or communication start 
--time 
END TIME: FLOAT; -- task or communication end time 
TASK ID: MY_ATOM; -- task identifier 
IS_COMM: BOOLEAN; -- communication or task 
-- execution time 
TASK_FROM: MY_ATOM; -- message sender 
TASK_DESTIN: MY_ATOM; -- message receiver 


end record; 


-- Queue that is used by the longest path cost algorithm 
-- included in the procedure CONSTRUCT_TASK_FLOW 
package NEW _QUEUES is new QUEUES2 (MY_ELEMENT) ; 


--Array that keeps the schedule for every processor 
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type SCHEDULE ARRAY is array(MY_ATOM) of EXECUTION_INFO; 
THE SCHEDULE: SCHEDULE_ARRAY; 


--Array that is used by the scheduler 
type TIME ARRAY is array(PROCESSOR) of FLOAT; 
Met iME: TIME ARRAY; 


-- Used for instantiation of the package GRAPH2_ ADT 
procedure PRINT _OUT(ELEMENT: in MY ELEMENT; ELEMENT KEY: 
ii NT BGER ); 


--Instantiation of the package GRAPH2 ADT 
package MY_DGRAPHS is new 
GRAPH2_ADT(MY ELEMENT, INTEGER, PRINT OUT); 
use MY DGRAPHS; 


-- Used for instantiation of package SORT_ADT 
function LESS THAN (El, E2: MY RECORD) return BOOLEAN; 


-- Instantiation of the package SORT ADT 

package NEW_SORT is new SORT_ADT(MY_RECORD, INTEGER, 
LESS THAN); — 

use NEW_SORT; 


DG: DGRAPH; -- directed graph 
-- abstract data type 
RESULT SET: SET := MY_DIS.CREATE; -- set tha contains the 


-- tasks that compose the longest path cost 
HEUR_ARRAY: SORT_ARRAY(1..MAX ARRAY);-- array with values 
-- that were calculated by heuristic function 


-- Procedure used in the instantiation of the package 

-~- GRAPH2_ADT. 

-- This procedure prints the element key(task identifier) 
-- and the execution cost associated with the task.It also 
-- accumulates the uniprocessor execution time and counts 
-- the number of tasks in the task flow. This procedure 
-- is used by the traversals depth_first_search 

-- and breadth _first_search of the package MY_DGRAPHS. 
procedure PRINT OUT(ELEMENT: in MY ELEMENT; ELEMENT KEY: 
in INTEGER) is 


begin 
PUT(ELEMENT_ KEY, WIDTH => 4); --prints task identifier 
PUT ( ub a“ ) K 


PUT(ELEMENT.INFO, FORE => 2, AFT => 2, EXP => 0); 
--prints task execution cost 
NEW_LINE; 
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if AUX COUNT < MAXUPROGESS epee 


AUX_COUNT := AUX_COUNT + 1; -- counts the number of 
-~- tasks 
AUX_COST := AUX_COST + ELEMENT. INFO; --accumulates 
-- uniprocessor execution cost 

end 1:7 


end PRINT OUT; 


-- Function used for instantiation of the package SORT_ADT 


function LESS THAN (El, E2: MY _ RECORD) return BOOLEANMae 


begin 
if ElL.HINFO < E2.HINFO them 
return TRUE 
else 
return FPALSE; 
end if; 
end LESS _THAN; 


-- Prints all atoms that compose a set 
procedure PRINT SEP( A: SET )e is 


begin 
fer 1 in 1 MAX TPROCESS loop 
if MY_DIS.MEMBER(MY_ATOM(I), A) then 
BUT CL) WoDme => oP 
end we: 
end loop; 
NEW_LINE; 
cidePRENT Tse. 


-- Prints one processor 
procedure PRINT PROCESSOR( PROC: PROCESSOR, Sipe RGe. 
PROCESSOR) is 


AUX_INDEX: INTEGER := 0; 


begin 
for I in PROCESSOR FIRST. .L BROC Hoos 
AUX INDEX == AUXU INDEX 
af 1 ="PROC then 
PUT( "Tasks Allocated toeBR iy), 
PUT(AUX_INDEX, WIDTH => 1); 
PUT LINE( “/Ueilisarionuas 
exit: 
end ir? 
end loop; 
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Grid SPRINT TPROCESSOR; 


-- Finds in which processor the task is allocatted 
procedure FIND_PROCESSOR(P: in PROCESSOR_ARRAY; 
IN ATOM: in MY_ATOM; 
ime ROG mie ROCKS SOR; 
SUCCESS: @ute BOOLEAN; 
CUTSPROCHSSOR, -OuG PROCESSOR) is 


OK: BOOLEAN := FALSE; 


begin 
PO@e le tie PROCHSGSOR FIRST le PROC loop 
OK := MY_DIS.MEMBER(IN_ ATOM, P(I)); 
ar OR, then 
SUGCESS == OK; 
OUTSPROCESSOR == 1; 
exit; 
end if; 
end loop; 
end FIND PROCESSOR; 


-- Constructs one example of task flow and returns a set 
-- that contains all tasks that are in its longest path 
-- cost. 
procedure CONSTRUCT_TASK FLOW(G: in out DGRAPH; 
OUD SEL: yin out SET) 
is separate; 


-- Calculate heuristics for each edge of the directed 
-- graph giving the results in TEMP_ARRAY in accordance 
-- with the heuristic function specified by 
-- HEUR.TEMP_ARRAY is sorted in increasing order using the 
values of the calculated heuristics 
renee CALC_HEURISTIC(G: in out DGRAPH; 
TEMP ARRAY: in out SORT _ARRAY) 
is separate; 


-- Allocate tasks to processors. 
procedure ALLOCATE(G: in out DGRAPH; LAST_PROC: out 


PROCESSOR; 

TEMP ARRAY: in out SORT ARRAY; 

TEMP USET> in out SET; —-longest path 
-- cost set 


PROC_ARRAY: in out PROCESSOR_ARRAY; 
UTIL ARRAY: in out UDELL ZATION. ARRAY; 
ALLOCATED | TASKS: in out SET) is separate; 


thea 


-- Schedule tasks on each processor 
procedure SCHEDULE(G: in out DGRAPH; 
L_PROC: in PROCESSOR; 
P; in out PROCESSOR ARRAY; 
S: in Ob SCHEDULE ARREae 
T: out TIME ARRAY) is separate; 


-- Improves the task allocation 
procedure IMPROVE is separate; 


begin 
CONSTRUCT _TASK_FLOW(DG,RESULT_SET); 
CALC HEURISTIC( DG, HEURTARERAY 7; 
ALLOCATE (DG, LAST PROCESSOR, HEUR ARRAY, RESULT ESE, 
P_ARRAY,U_ARRAY,ALLOCATED_ TASKS) ; 
SCHEDULE (DG, LAST PROCESSOR, P_ARRAY,THE SCHEDULE,MY_ TIME); 
if LAST PROCESSOR — P4 then 
IMPROVE; 
end if; 


end STATICAL? 


B. CTFLOW.ADA 


separate(STATICAL) 


procedure CONSTRUCT TASK FLOW(G: in out BEGRAPH, 
OUT SET inoue SET jas 


TITLE: STRING (i305. 
TITLE LENGTH: NATURAL; 
SUCCESS: BOOLEAN; 

FILE NAME: STRING(1..30); 
NAME _ LENGTH: NATURAL, 
INES FILE TYPE, 

MY STRING. SR ING Gla): 
MY NODE: INTEGER; 
MY _ EXE: FLOAT; 

MY_FROM: INTEGER; 

MY TO; INTEGER; 

MY COST: FEAT; 


COMIJ: MY_ELEMENT; 
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function CONVERT(E: FLOAT) return MY_ELEMENT is 


MY DATA: MY_ELEMENT; 


begin 
MY_DATA.PROCESS SET := MY_DIS.CREATE; 
MY_DATA.INFO := E; 


ee Mistletoe, 
end CONVERT; 


procedure FIND LONG PATH(DG: in out DGRAPH; OUT SET: in out 
SET) is 


Eee n2, BS: MY ELEMENT; 
SUCCESS: BOOLEAN; 

Poon: SEL, 

ACC: FLOAT; 

MAX: FLOAT; 

AUX_QUEUE: NEW_QUEUES.QUEUE; 


begin 
NEW QUEUES.CREATE(AUX QUEUE, SUCCESS); 
Pomel ney i, . MAX PROCESS oop 
RETRIEVE _NODE(DG, I, El, SUCCESS); 
Pienoe MY DIS. MEMBER(MY ATOM(1), El. PROCESS SET) then 
El.ACCUMULATOR := E1.ACCUMULATOR + E1.INFO; 
MY DIS.INSERT(MY_ATOM(I), E1l.PROCESS_SET); 
UPDATE _NODE(DG, I, El, SUCCESS); 
end if; 
Pores tn 1. .MAX PROCESS, Joop 
af I /= J then 
REDRMEVEMEDGE( DG, I, ud, B2, SUCCESS); 
it SUCCESS, then 
RETRIEVE NODE(DG, J, E2, SUCCESS); 
if SUCCESS and J=1 then 
RETRIEVE NODE(DG, I, E3, SUCCESS); 
NEW_QUEUES.ENQUEUE(AUX_QUEUE, E3); 
else 
ACG 3— 981 ACCUMULATOR + E2. INFO; 
Dice > EZ .ACCUMULATOR then 
E2.ACCUMULATOR := ACC; 
E2. PROCESS SET := El.PROCESS SET; 
MY DIS.INSERT(MY_ATOM(J), E2.PROCESS_SET); 
UPDATE NODE(DG, J, E2, SUCCESS); 
end if; 
end if; 
endecn. 
end i; 


end loon: 

end wleor: 

MAX := 0.0; 

while not NEW_QUEUES.EMPTY(AUX_QUEUE) loop 
NEW QUEUES.SERVE( AUX OUBUE Ey, 
if E1.ACCUMULATOR > MAX then 


MAX := E1.ACCUMULATOR; 
OUT_SET <= El. PROCESSe OER, 
end if; 
end loop; 


end FIND LONG PATH; 


begin 
--creates the directed graph 
CREATE(G, SUCCESS); 
if net SUCCESS then 
raise DGRAPH_ ERROR; 
end if; 


PUT LINE(*Enter file with input data”): 
GET_LINE(FILE_NAME,NAME_LENGTH); 
OPEN(INF, MODE => IN FILE, NAME => 
FILE NAME(1..NAME LENGTH) ); 
GET_LINE(INF,TITLE, TITLE LENGTH); 
PUT LINE (TITLE 1..TITLED PENGTH)); 
while not END OF FILE INF) loop 
GET(INF,MY_ STRING); 
if MY_STRING = "NODE" then --insert a node 
GET( INF ,MY NODE); 
GET(INF,MY EXE); 
INSERT _NODE(G, MY_NODE, CONVERT(MY_ EXE), SUCCESS); 
else -- insert an edge 
GET(INF,MY FROM); 
GET(INF,MY TO); 
GET INE, MY seOST); 
INSERT_EDGE(G, MY_FROM, MY_TO, CONVERT(MY_COST), 
SUCCESS); 
end if; 
SKIP_LINE(INF); 
ena loop; 


-- search and print elements of the created graph 
PUT LLINE( “Breadth Pimst Seareuuye, 
BREADTH FIRST SEARCH(G); 


NUM_OF_TASKS := AUX COUNT; 
MAX INDEX := (NUM_OF_TASKS*(NUM_OF_TASKS-1) )/2; 
NEW_LINE; 


PUT LINE("Number of Tasks = "); 
PUT (NUM OF TASKS, WIDTH —> 2); 
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NEW_LINE; 

UNEEeecOST 7= AUX COST: 

-- print uniprocessor execution time 

PUL LUNE WInipEecessor Hxecution Time”); 
Domne XeMeOST NORM e=> 4, AFT =) 4, EXP => 0); 
NEW LINE; 


PUT _LINE("Depth First Search"); 
DEPTH FIRST _SEARCH(G); 


--find the longest path 
FIND LONG PATH(G,OUT_SET); 
PUT_LINE( "LONG PATH"); 
PRINT SET(OUT_SET); 


-- initializes parent array 
PUTeEOWE(- Parent drray calculation”); 
Got Jets. .NUM OF TASKS loop 
Pomme ile ie OOD 
RETRIEVE EDGE(G, I, J, COMIJ, SUCCESS); 
PioeoUCORSs then 
MY DIS. INSERT(MY_ATOM(I),PARENT ARRAY(MY_ATOM(J))); 
end if; 
send) loop, 
PRINT _SET(PARENT_ARRAY(MY_ATOM(J))); 
end loop; 


--initializes ancestor array 
PUT LINE("Ancestor array calculation"); 
teamed in 2..NUM OF TASKS loop 
forel an i. .J—-l1 loop 
RETRIEVE EDGE(G, I, J, COMIJ, SUCCESS); 
Memes UCCE Ss then 
MY _DIS.INSERT(MY_ATOM(I),ANCESTOR_ARRAY(MY_ATOM(J))); 
tie y= 1 then 
ANCESTOR _ARRAY(MY_ATOM(J)) := 
MY_DIS.UNION(ANCESTOR_ARRAY(MY_ATOM(J)), 
ANCESTOR_ARRAY(MY_ATOM(I))); 
end if; 
end ii: 
end loop; 
PRINT SET(ANCESTOR_ARRAY(MY_ATOM(J))); 
end loop; 


end CONSTRUCT TASK FLOW; 


kiss) 


C. CALHEU.ADA 


separate(STATICAL) 


procedure CALC_HEURISTIC(G: in out DGRAPH; 
TEMP_ARRAY: in out SORT ARRAY) is 


SUCCESS: BOOLEAN; 

SUCCESS1, SUCCESS2: BOOLEAN; 

VALUE: INTEGER; 

type H_FUNCTION is array(1..MAX PROCESS, 1..MAX_ PROCESS jae. 
FLOAT; 


H: H FUNCTION :;= (others => (others —» 0709) 
Cid, Bil, 202 hy Seca; 
COUNT: INTEGER := 0; 


IS_MEMBER: BOOLEAN; 
AUX _TERM: FLOAT; 


funchion HEURISTICI(EXI, EXJ, COMIJ: MY ELEMENT) Srecuied 
FLOAT is 


begun 
return (0.5*COMIJ.INFO + (0.5/(EXI.INFO+EXJ.INFO))); 
end HEURISTIC. 


procedure PRINT HEADER is 


begin 
LEAT iO. PUL SEN J joe EJ Cig be piidhes )) 
end PRINT HEADER; 


begin 
for I in 1..NUM_OF TASKS=1 doop 
for J in I+1..NUM_OF TASKS loop 
COUNT := COUNT + 1; 
MY_DIS.INSERT(MY_ATOM(I), TEMP ARRAY (COUNT) .PAIR SHT}y 


TEMP ARRAY(COUNT).INDEX FROM := I; 
MY_DIS.INSERT(MY_ATOM(J), TEMP _ARRAY(COUNT) .PAIR_SET); 
TEMP ARRAY(COUNT).INDEX_TO := J; 


RETRIEVE NODE(G, 1, EL; SUCGESSigE 
it not SUCCESS!) Enen 

El. INFO := 020; 
end if; 
RETRIEVE NODE(G, J, HI, oUGeE Seer, 
i= not SUCCESS? then 
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Poin Ow 0.0; 


uasl) alse 2 
REUSE PROCH(G,.1, dc, Cid, SUCCESS): 
AUX_TERM := 0.0; 
iienezce SUCCESS then 
Gijstire . “= 00> 
IS MEMBER := MY _DIS.MEMBER(MY ATOM(I), 


ANCESTOR _ARRAY(MY ATOM(J))); 
if IS MEMBER then 


AUROTERM) 2= 1.07 
end if; 
Gietel Sites 
iiesUCCESsSl and SUCCHESS2 chen 
HGlwie 7 = HEURTSTECM@BT, FU, Cld): 
else 
HCE des = 0.0 + 
end if; 
TEMP ARRAY(COUNT) .EFROM := EI.INFO; 
TEMP ARRAY (COUNT) .ETO = Ho. INFO= 
TEMP ARRAY(COUNT).COMM := CIJ.INFO; 
TEMP ARRAY(COUNT).HINFO := H(I,d); 
end loop; 
end loop; 


NEW_SORT.QOS_3(TEMP_ARRAY(1..MAX_INDEX) ); 

PRINT HEADER; 

Hom l in i..MAX INDEX loop 
PUT(TEMP ARRAY(I).INDEX FROM, WIDTH => 2); 
PUT(" "); 
PUT(TEMP ARRAY(I).INDEX TO, WIDTH => 2); 
PUT(" "); 
PUT(TEMP_ARRAY(1I).EFROM, FORE => 2, AFT => 3, EXP => 0); 
PUT(" "); 
PUT(TEMP_ARRAY(I).ETO, FORE => 2, AFT => 3, EXP => 0); 
PUT(" "); 
BUT TEMPOARRAY(1).COMM, FORE => 2, AFT => 3, EXP => 0); 
PUT(" "); 
PUPCITEMPUARRAY(21)-HINFO, FORE => 2, AFT => 3, EXP => 0); 
NEW_LINE; 

end loop; 

enae CALC HEURISTIC; 


AY 


D. ALLOC.ADA 


Separate ( STATIGAL) 


procedure ALLOCATE(G: in out DGRAPH; LAST _PROC: out 
PROCESSOR; 
TEMP_ARRAY: in out SORT_ARRAY; 
TEMP_SET: in out SET; PROC ARRAY: ingore 
PROCESSOR_ARRAY; 
UTIL ARRAY: in out UTILIZATIONNS RR ees 
ALLOCATED TASKS: in out SEP jews 


L_ PROC: PROCESSOR; 
TOP_DOWN_INDEX: INTEGER; 
BOTTOM UP INDEA; INTEGER <— i 
PAIR_TOGETHER, PAIR SEPARATED: SET; 
ALLOCATED: BOOLEAN; 

SET TO. ALLOG. See; 

BOTH: BOOLEAN; 

PROC_USED: PROCESSOR; 
CURRENT_ATOM: MY_ATOM; 

CURRENT SED. SE; 

CURRENT PROCESSOR: PROCESSOR; 
VAR_UTILIZATION: FLOAT; 


function FIND LEAST USED PROCESSOR(UTIL: UTILIZATION ARRAY) 
return PROCESSOR is 
LUP: PROCESSOR := PROCESSOR FIRST: 


begin 
for I in PROCESSOR’ SUCC( PROCESSOR’ FIRST) Ll PROG Bios 
f£ UTIL(1) < UTIN(LUP) then 
LUE =i; 
end if; 
end loop; 
retugcn LUP; 
end FIND LEAST USED PROCESSOR; 


Function FIND LEAST USED PROCESSOR (ULTE. UTILIZATION _ ARRAY; 
PROC: PROCESSOR) 
return PROCESSOR is 


LUP: PROCESSOR; 
FIRST: BOOLEAN ;— TRUE; 


begin 
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Poin ROCK SSOR PIRST..L PROG loop 
fe l= PROG then 
if FIRST then 
LUP := I; 
PIRST = FALSE: 
else 
PUL ry ee UTIN( LUE) then 
cue = i; 
end if; 
ence t = 
end it; 
end loop; 
ene beg, IEIC) Ss) 
Gna FIND LEAST USED PROCESSOR; 


procedure ADDITIONAL UTILIZATION(ADDED_ TASKS: in out SET; 
ACCUM: out FLOAT) is 


ACC: FLOAT := 0.0; 

THE KEY: MY_ATOM; 
Pope eo MENT: MY ELEMENT; 
OK: BOOLEAN := TRUE; 
SUCCESS: BOOLEAN; 


begin 
MY DIS.TAKE OUT MEMBER(ADDED TASKS, THE KEY, OK); 


while OK loop 
RETRIEVE NODE(G, INTEGHR(THE KEY), THE ELEMENT, 


SUCCESS); 

2CCy.— ACG] + THE ELEMENT. INFO; 

MY DIS.TAKE OUT _MEMBER(ADDED TASKS, THE KEY, OK); 
end loop; 


ACCUM := ACC; 
end ADDITIONAL UTILIZATION; 


procedure ALLOCATE SET_OF TASKS TO PROCESSOR(SET_OF_TASKS: 
sigat ee 
PROCESSOR _DEST: in 
PROCESSOR; 
ALLOCATED TASKS: in out 
SET; 
DELTA_UTILIZATION: in out 
FLOAT; 
USERRA Th Our 
UTILIZATION ARRAY; 
P_ ARRAY: in out 
PROCESSOR_ARRAY) is 


ADDED_TASKS: SET; 


begin 
ADDED _TASKS := MY_DIS.DIFFERENCE( SET IGRSIAS 
ALLOCATED_TASKS); 
ALLOCATED_TASKS := MY_DIS.UNION(SET OF _ TASKS, 
ALLOCATED TASKS); 
P_ARRAY(PROCESSOR_DEST) := MY_DIS.UNTON(SET OP RTASKS? 
P ARRAY(PROCESSOR_DEST)); 
ADDITIONAL UTILIZATION(ADDED_TASKS, DELTA_UTILIZATION) ; 
U_ARRAY(PROCESSOR_DEST) := U_ARRAY(PROCESSOR_DEST) + 
DELTA_UTILIZATION; 

end ALLOCATE _SET_OF_TASKS_TO PROCESSOR; 


procedure IS_PAIR_ALLOCATED (PAIR: in SET; 
ANSWER: out BOOLEAN; 
TO BE LALLOG- "outesau 
ALLOCATE BOTH: out BOOLEAN; 
ALREADY _USED: out PROCESSOR) 
is 


AUA. Ski; 
USED: INTEGER; 
AUX_PROCESSOR: PROCESSOR := Pl; 


AUX_ATOM: MY_ATOM; 
OK: BOOLEAN; 


begin 
AUX := MY_DIS.INTERSECTION(PAIR, ALLOCATED TASKS) ; 
USED := MY DIS.COUNT_ MEMBERS(AUX); 
if USED = 2 then 
ANSWER := TRUE; 
else 
ANSWER := FALSE; 
TO BE ALLOC := MY DIS.DIFFERENCH(PAIR, AURA); 


if USED = 1 then 
MY DIS.TAKE OUT MEMBER(AUX, AUX_ATOM, OK); 
FIND PROCESSOR(PROC_ARRAY, AUX_ATOM, L_PROC, OK, 
AUX_PROCESSOR) ; 


ALREADY_USED := AUX_PROCESSOR; 
ALLOCATE BOTH := FALSE; 
else 
ALLGCATE BOTH :>= TRUE; 
ALREADY_USED := AUX_PROCESSOR; 
end if; 
end ii: 


end IS_PAIR_ALLOCATED; 


procedure ALLOCATE PAIR_SEPARATE is 
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SUCCESS: BOOLEAN; 


begin 
-- allocatte separate tasks 
DS PATR ALLOCATED(PAIR SEPARATED, ALLOCATED, SET TO _ALLOC, 
BO ee PROC USED); 


if not ALLOCATED then -- there is at least one task not 
-- allocated 
if not BOTH then -- only one must be allocated 


CURRENT PROCESSOR := 

FIND_LEAST USED PROCESSOR(UTIL_ARRAY, PROC_USED); 

Minocnth Shi Or TASKS TO PROCESSOR(SET TO ALLOC, 
CURRENT PROCESSOR, 
ALLOCATED _ TASKS, 
VAR_UTILIZATION, 
UTIL ARRAY, 
PROC ARRAY); 

else 
CURRENT PROCESSOR := 
FIND LEAST USED PROCESSOR(UTIL ARRAY); 


CURRENT_SET := SET TO ALLOC; 
MY _DIS.TAKE OUT MEMBER(SET TO ALLOC, CURRENT ATOM, 
SUCCESS); 


ALLOCATE SET OF TASKS TO PROCESSOR(SET TO ALLOC, 
| CURRENT PROCESSOR, 

ALLOCATED TASKS, 
VAR_UTILIZATION, 
UTIL ARRAY, 
PROC ARRAY); 

SET TO ALLOC := MY _DIS.DIFFERENCE(CURRENT SET, 

CH MTOUALEOC); 

CURRENT PROCESSOR := 

FIND LEAST USED PROCESSOR(UTIL_ARRAY); 

ALLOCATE SET OF TASKS TO PROCESSOR(SET TO ALLOC, 
CURRENT PROCESSOR, 
ALLOCATED TASKS, 
VAR_UTILIZATION, 
UTIL ARRAY, 
PROC_ARRAY); 


end if; 
end if; 
end ALLOCATE PAIR SEPARATE; 
procedure ALLOCATE PAIR TOGETHER is 
begin 


-- allocate tasks that should be together 
IS_PAIR_ ALLOCATED(PAIR_TOGETHER, ALLOCATED, SET_TO_ALLOC, 


Ny ak 


BOTH, PROC_USED); 
if not ALLOCATED then -- at least one should be allocated 
tf NOt eSOTH then -- allocate only one task 
if PROG USED) — Fle then 
CURRENT PROCESSOR: : = 
FIND LEAST _USED_PROCESSOR(UTIL_ARRAY, P1); 
ALLOCATE SET _OF TASKS TO PROCESSOR(SET TO ALLOC, 
CURRENT_PROCESSOR, 
ALLOCATED TASKS, 
VAR_UTILIZATION, 
UTiG ARRew 
PROC_ARRAY); 


else 
ALLOCATE SET OF TASKS TO PROCESSOR(SET_TO_ALLOC, 

PROC USED? 
ALLOCATED TASKeer 
VAR_UTILIZATION, 
UTIL_ARRAY, 
PROC_ARRAY); 

ene it; 

else 


CURRENT PROCESSOR := 

FIND LEAST USED PROCESSOR(UTIL_ ARRAY); 

ALLOCATE_SET_OF TASKS TO PROCESSOR(SET_TO ALLOC, 

: CURRENT_PROCESSOR, 
ALLOCATED _TASKS, 
VAR_UTILIZATION, 
UTIL ARRAY, 
PROC ARRAY); 
end 1c 
end if; 


end ALLOCATE PAIR _TOGETHER; 


-- get the options from keyboard 
procedure GET OPTIONS(L PROC: ouG PROCESSOR) ea. 


procedure QUERY_NR_OF PROCESSORS(P: out PROCESSOR) is 
NUM_PROC: INTEGER; 


begin 
PUT_LINE("Please, enter number of processors?"); 
GET(NUM_ PROC); 
case NUM_PROC is 
when 1 => 


P := Pl; 
when 2 => 
P 3;= P2; 
when 3 => 
P 2= PSs 


when 4 => 
Ey Ps 
when 5 => 
Po s= P5; 
when 6 => 
P := P6; 
when 7 => 
P := P7; 
when 8 => 
P := P8; 
when 9 => 
P := P9; 
when 10 => 
P := P10; 
when others => 
P := P10; 
end case; 


end QUERY_NR_OF PROCESSORS; 


begin 
QUERY _NR_OF_ PROCESSORS(L_ PROC); 
end GET OPTIONS; 


begin 


TOP_DOWN_INDEX := MAX_INDEX; 

-- starts the allocation 

CURRENT_PROCESSOR := 

FIND LEAST USED PROCESSOR(UTIL_ARRAY) ; 

ALLOCATE SET OF TASKS TO PROCESSOR(RESULT SET, 
CURRENT PROCESSOR, ALLOCATED TASKS, VAR_UTILIZATION, 
UTIL_ARRAY, PROC_ARRAY); 


-- print potential parallel execution time 

FteatNe(  FOtenttal Parallel Execution Time: “”); 
PUT(VAR_UTILIZATION, FORE => 4, AFT => 4, EXP => 0); 
NEW_LINE; 


-- print potential speed-up 

POTENTIAL SPEED UP := UNI_EXE COST/VAR_UTILIZATION; 

UT. _LINE("Potential Speed-Up: "); 

BUT(POTENTIAL SPEED UP, FORE => 4, AFT => 4, EXP => 0); 
NEW LINE; 


GET_OPTIONS(L_ PROC); 
[eter NE SDokrom up top down “); 
woaile (not MY DES.IS FULL(ALLOCATED TASKS)) and then 


(BOTTOM TUP INDEX <= TOP _DOWN_INDEX) loop 
PUT (BOTTOM __ UPS INDEX, WIDTH => )) 3 


LT 3 


PUL a 
PUT(TOP_ DOWN INDEX, WIDTH => 6); 


NEW_LINE; 
PAIR_SEPARATED := TEMP_ARRAY(BOTTOM_UP_INDEX).PAIR_SET; 
BOTTOM _UP_INDEX := BOTTOM _UP_INDEX + 1; 

PAIR_TOGETHER := TEMP_ARRAY(TOP_DOWN_INDEX).PAIR_SET; 
TOP DOWN INDEX := TOP DOWN_INDEX - 1; 


ALLOCATE PAIR_SEPARATE; 
ALLOCATE PAIR_TOGETHER; 
end loop; 


for I in PROCESSOR’'FIRST..L PROC loop 
PRINT _PROCESSOR(I, L_PROC); 
PRINT SET(PROC_ARRAY(I)); 
PUT(UTIL ARRAY(1), FORE => 4, AFT => 4) Ex Pao mere 
NEW LINE; 
end loop; 


LASTIPROG 4 — yi) PROG; 


end ALLOCATE; 
E. SCHED.ADA 


separate(STATICAL) 


procedure SCHEDULE(G: in out DGRAPH; 
L PROC: in PROCESSOR; 
P: in out PROCESSOR_ARRAY; 
S23 in Out SCHEDULE, ARRAY, 
T: out TIME ARRAY) is 


MY P: PROCESSOR_ARRAY := P; 
MYT: TIME ARRAY “:= (others —> 020)- 


procedure SCHEDULE TASKS(G: in out DGRAPH ae. sain 
PROCESSOR_ARRAY; 
S: in out SCHEDULE TARRAY ma 


MY SCHEDULE: SCHEDULE ARRAY; 

SUCCESS: BOOLEAN; 

CURRENT PROCESSOR, SOURCE PROCESSOR: PROGESSOks 
CURRENT ELEMENT, EDGE ELEMENT: MY_ELEMENT; 
--type TIME ARRAY is array(PROCESSOR) of FLOAT; 
--MY TIME: TIME ARRAY := (others => 0.0); 

MY _INFO: EXECUTION INFO; 

AUX_INFO: EXECUTION _INFO; 

type AUX ARRAY is array(MY_ATOM) of FLOAT; 
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EXTRA ARRAY: AUX_ARRAY := (others => 0.0); 
FOUND: BOOLEAN := FALSE; 


function MAXIMUM(X,Y,W: FLOAT) return FLOAT is 
Z: FLOAT := X; 


begin 
ie Y 2 4 clren 
“os 
end if; 
ie W > 24 then 
Aa = ON 
end if; 
me CUirny 4, 
end MAXIMUM; 


begin 
fer i in MY ATOM’FIRST..MY ATOM’LAST loop 
FIND PROCESSOR(P, I, L PROC, SUCCESS, 
CURRENT PROCESSOR); 
REPRIEVE NODE(G, INTEGER(1I), CURRENT ELEMENT, SUCCESS); 
if I = 1 then 
MY INFO.START TIME 
MY_ INFO.END _ TIME 
CURRENT __ ELEMENT. INFO 
MY INFO. TASK ID ie 
MY_ INFO.IS _COMM FALSE; 
MY_ J CuRRaae PROCESSOR) MY INFO.END TIME; 
MY SCHEDULE(MY_ATOM(1) ) MY INFO; 
else 
Petri) My sa tOM FIRST. .MY ATOM’PRED(1) loop 
if I /= J then 
RETRIEVE _EDGE(G, INTEGER(J), INTEGER(I), 
EDGE ELEMENT, SUCCESS); 
if SUCCESS then 
AUX INFO := MY _SCHEDULE(MY_ATOM(J)); 


MY T( CURRENT SPROCESSOR); 
MY INFO.START TIME + 


1 | i || 


FOUND := FALSE; 
MY_INFO.START TIME := MAXIMUM(AUX INFO.END TIME, 
EXTRA ARRAY(1), 
MY _T(CURRENT PROCESSOR) ); 
EXTRA ARRAY(I) := MY_INFO.START_ TIME; 
eng af 
eine aay 
end loop; 
Mee EOS END OTIME =:— MY INFO. START TIME + 
CURRENT ELEMENT. INFO; 
MY SINFO. TASKeID := I; 
MY INFO.IS COMM := FALSE; 
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MY_T(CURRENT_PROCESSOR) 
MY SCHEDULE (MY_ATOM(1I) ) 
end Ey 
end loop; 
S := MY SCHEDULE; 
end SCHEDULE_TASKS; 


MY_INFO.END_ TIME; 
MY INFO; 


procedure PRINT_SCHEDULE(S: in out SCHEDULE _ ARRAY; 
P: in out PROCESSOR_ARRAY) is 


FOUND: BOOLEAN := FALSE; 
SUCCESS: BOOLEAN := TRUE; 
CURRENT_ATOM: MY_ATOM; 
CURRENT INFO: EXECUTIONS ENEO-; 


procedure PRINT_P(PROC: in PROCESSOR) is 
AUX_INDEX: INTEGER := 0; 


begin 
for I in PROCHSSOR FIRST LerPROC lea. 
AUX_INDEX := AUX_INDEX+1; 
if I = PROC then 
PUT PROCESSORS Ee ), 
PUT(AUX INDEX, WIDTH —> 1); 
NEW LINE; 
exit; 
end if; 
end loop; 


PUT DINE ("START END DES eu. 


end PRINT SE? 


begin 
for I in PROCESSOR’ FIRST .. lb PROG legs 
PRINT P(I); 


MY _DIS.TAKE OUT MEMBER(MY P(1), CURRENT ATOM, SUGGES oe 
while SUCCESS loop 


CURRENT_INFO := S(CURRENT_ATOM); 
PUT(CURRENT_INFO.START TIME, FORE => 4, AFT => 4, EXP 
=> 0); 
siete sae ee 
PUT(CURRENT_INFO.END TIME, FORE => 4, AFT => 4, EXP 
=> /0)4 
Eu Pan 
PUT( INTEGER(CURRENT_INFO.TASK_ID), WIDTH => 2); 
NEW LINE; 
MY_DIS.TAKE_OUT_MEMBER(MY_P(1I),CURRENT_ATOM, SUCCESS); 
end locp; 


end loop; 
end PRINT_SCHEDULE; 


begin 
SCHEDULE TASKS(G,P,8)j; 
PRINT SCHEDULE(S,P); 
tee = Mir, 

end SCHEDULE; 


F. IMPROVE.ADA 


separate(STATICAL) 


procedure IMPROVE is 


--Data for improvement of the task allocation by pairwise 
exchange of tasks 

CURR_P_ARRAY: PROCESSOR_ARRAY := (others => MY_DIS.CREATE); 
CURR_ THE_ SCHEDULE: SCHEDULE ARRAY; 

CURR _ uae TIME: TIME _ARRAY; 

COST ARRAY: TIME ARRAY; 

CURR_ COST_ARRAY: TIME ARRAY; 

eT COST: TIME _ARRAY; 

CURR_ TOTSCOSsT: TIME _ARRAY; 


type TOPOLOGY COST ARRAY is array(Pl..P4,P1..P4) of FLOAT; 
HOP ARRAY: TOPOLOGY COST ARRAY := ((0.0,1.0,2.0,1.0), 
Gor 00) 10,2 One 
(er O HO) 0.0., 150): 
(VO, 2 ipl (0) 0) ACB 


SET COUNT, INDICATOR: INTEGER; 
GUESS: FLOAT; 

CONTROL SET: SET MY DIS.CREATE; 
Buen SohT 2 ge leit MY DiS CREATE. 
type CHANGE ARRAY is array(MY_ATOM) of MY_ATOM; 
SWAP ARRAY: - CHANGE _ARRAY; 

mits ATOM: MY _. ATOM; 

SUCCESS: BOOLEAN; 

PROC], PROC2: PROCESSOR; 

MAX COST: FLOAT; 

CURR_MAX COST: FLOAT; 


LF 7 


== Calculates e€ese arunay 

procedure CALC _COST_ARRAY(G: in out DGRAPH; 
P; in out PROCHSSORBAR Rg, 
C_ARRAY: out TIME ARRAY) is 


TEMP COST ARRAY: TIME ARRAY <= (Gunlerse— > s0ntan 
COST _ELEMENT: MY _ ELEMENT; 

PROD_COST: FLOAT; 

SUCCESS: BOOLEAN, 

PROC FROM, PROC TO: PROCESSOR; 


begin 
Por 1 an vl. NUMeCORsI Asks Woop 
for J ai) a. NUM On SUA Sks loop 


if I /= J then 
RETRIEVE EDGE(G, I, J, COST ELEMENT, GutCeihec or 
if SUCCESS then 
FIND_PROCESSOR(P,MY_ATOM(1),P4,SUCCESS, PROC ERoigs 
FIND PROCESSOR(P,MY ATOM(J),P4,SUCCESS,PROC_TO); 


if PROC_FROM /= PROC_TO then -- if they are in 
dif. processors 
PROD COST =- 


HOP _ARRAY(PROC_FROM,PROC_TO)*COST ELEMENT. INFO; 
TEMP -COST_ARRAY(PROC_FROM) := 
TEMP COST ARRAY(PROC_FROM) + 


PROD COST; 
TEMP COST ARRAY(PROC TO) := 
TEMP COST ARRAY(PROC TO) + 
PROD ICOST; 
end if; 
end if; 
end if; 
end loop; 
end loop; 
C_ARRAY := TEMP COST ARRAY; 


end CALC COST ZARRAY; 


funce Lon: FIND _MAX_COST(T_ARRAY: in TIME ARRAY) 
return FLOAT is 


MAX: FLOAT := T_ARRAY(P1); 


begin 
for I im P2..P4 loop 
if T_ARRAY(1I) > MAX then 
MAX := © ARRAY(1); 
end if; 
end Loop, 
return MAx; 


ays 


end FIND MAX COST; 
procedure PRINT_NODE_ PROCESSOR(P: in PROCESSOR) is 


begin 
case P is 
when Pl => 
PUG(e PI"): 
when P2 => 
PUiG@ee2. ) 
when P3 => 
PUT("P3"); 
when P4 => 
PUT(*P4"); 
when others => 
Ture ess 
end case; 
end PRINT NODE PROCESSOR; 


procedure PRINT_TOT_COST is 


begin 
PUT EINE (° PROCESSOR MY_TIME COST_ARRAY 
TOTAGeECOST™ ) 5° 
Gomer lL. Pa loop 


TOT COST(I) := MY _TIME(I) + COST ARRAY(I); 
PRINT_NODE_PROCESSOR(1) ; 

PUT( " DN 

PUT(MY_TIME(I), FORE => 4, AFT => 4, EXP => 0); 
PUT( " ie 

PUT(COST_ARRAY(I), FORE => 4, AFT => 4, EXP => 0); 
PUD) 2). 

PUT(TOT COST(I), FORE => 4, AFT => 4, EXP => 0); 
NEW LINE; 


end loop; 
end PRINT TOT COST; 


begin 
CALC_COST_ARRAY(DG,P_ARRAY,COST ARRAY); 
PRINT TOT COST; 
MexeeOST) -= FIND MAX COST( TOT COST); 


-- starts allocation improvement 
RANDOM.SET SEED; 
gor K gml..100 loop 
oG tein i... NUM OF ETASKS loop 
MY DIS. INSERT(MY ATOM(I),CONTROL_ SET); 
end loop; 
SET COUNT := NUM_OF TASKS; 


Las) 


for i in VayNUMSORMTASKS sloco 
GUESS := RANDOM.SRAND; 
for J in 1 2.SET oCOUNT Moe. 
if GUESS < (FLOAT(J)/FLOAT(SET COUNT} = then 
INDICATORM. =r 
exit; 
end if: 
end loop; 
for J ine ll]. shel seounNteleop 
MYDS. fake _OUT _MEMBER 
(CONTROL SET, THIS ATOM, SUCERss 
if J = INDICATOR then 


SWAP_ARRAY(MY_ATOM(I)) := THIS ATOM; 
else 
MY DIS. INSERT( THIS ATOM, AURSSE Ty, 
end if: 
end loop; 
CONTROLESEDT 2= AUASSET; 
Sel. COUNT == SET COUNT — a, 
MY _ DIS.CLEAR SEI Ae siadlor 
end loop; 


for I in W.. NUMSOr TASKS? 2) Loop 
FIND PROCESSOR(P_ARRAY,SWAP_ARRAY(MY_ATOM(2*I-1)), 
P4, SUCCESS, PROC] ji; 
FIND PROCESSOR(P_ARRAY,SWAP_ARRAY(MY_ATOM(2*1I)), 
P4,SUCCESS,PROC2); 
if (PROC1 = Pl or PROC2 = Pl) then 
MY DIS.INSERT(SWAP_ARRAY(MY_ATOM(2*I-1)), 
CURR_P_ARRAY(PROCL)); 
MY DIS.INSERT(SWAP_ARRAY(MY_ATOM(2*I)), 
CURR_P_ARRAY(PROC2) ); 
else 
if PROC] = PROCZ2 then 
MY DIS.INSERT(SWAP_ARRAY(MY_ATOM(2*I-1)), 
CURR_P_ARRAY(PROCL)); 
MY _DIS.INSERT(SWAP_ARRAY(MY_ATOM(2*I)), 
CURR] P ARRAY (PROCI) >) 
else 
MY _DIS.INSERT(SWAP_ARRAY(MY_ATOM(2*I-1)), 
CURR_P_ARRAY(PROC2)); 
MY _DIS.INSERT(SWAP_ARRAY(MY_ATOM(2*I)), 
CURR_P_ARRAY(PROC1)); 
end if; 
end sii: 
end Joop: 
if NUM OF "TASKS mod 2 >= lochen 
FIND _ PROCESSOR (P_ ARRAY, SWAP_ARRAY 
(MY_ATOM(NUM_OF TASKS) ),P4,SUCCESS,PROC1); 
MY DIS.INSERT(SWAP ARRAY 
(MY_ATOM(NUM_OF_TASKS)),CURR_P_ARRAY(PROC1)); 
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end if; 


PUT_LINE( "ITERATION" ) ; 
PUT(K, WIDTH => 3); 
NEW_LINE; 


fom in Pl. .P4 loop 
PRINT NODE PROCESSOR( 1); 
PU? mye 
PRINT_SET(CURR_P_ARRAY(I)); 
end loop; 


SCHEDULE (DG, LAST PROCESSOR, CURR_P_ARRAY, 
CURR_THE SCHEDULE,CURR_MY_ TIME); 
CALC_COST_ARRAY(DG,CURR_P_ ARRAY, 
CURR_COST_ ARRAY); 


topetoein Pil..P4° loop 


CURR_TOT_COST(I) := CURR_MY TIME(I) + 
CURR_COST_ARRAY(I); 

cide lecp; 

CURR_MAX_ COST := FIND _MAX COST(CURR_TOT COST); 


PUT _LINE("CURR MAX COST"); 

PUT(CURR_MAX: COST, FORE => 4, AFT => 4, EXP => 0); 
NEW_LINE; 

PUT LINE("MAX COST"); 

PUMA COsT HORE => 4, APT => 4, EXP => 0); 

NEW LINE; 


if CURR_MAX COST < MAX_COST then 


P_ ARRAY := CURR_P_ ARRAY; 

MY TIME := CURR _MY TIME; 

COST_ARRAY := CURR_COST_ARRAY; 

iOmeeoste:— CURR ETOT COST: 

MAxcOgT :—= CURR Max COST: 

THE SCHEDULE := CURR_THE SCHEDULE; 
end if; 


pomelein Pl ..P4 loop 
MY_DIS.CLEAR_SET(CURR_P_ARRAY(I)); 
end loop; 


Saas loop,; 
EUV GINE( “IMPROVED ALLOCATION" ); 


mor Doin Pl..P4 loop 
PRINT NODE_PROCESSOR(I); 


Its at 


PUT ( wu it } : 

PRINT SET (PUARRAY (Eps, 
end loop; 
PRING TOMRGOs tT, 


end IMPROVE; 


6 2 
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